The Error Object

[ LiB ]

Flash MX 2004 includes an Error object that makes it easy to set up traps for various conditions while your app runs . That is, it's basically a glorified if statement that will trigger code if certain conditions are met. The reason I made this like an epilogue at the end of the chapter is that it's really not a tool for debugging. It's an error trapequivalent to trapping an event. In addition, it only triggers at runtime (when your bugs should be well out of the way). In any event, I think it's worth documenting here.

The benefit is that for several different places in your code, you may have the same condition you're checking. Suppose, for instance, that you build a calculator. When the user attempts to divide by zero, you want to give the user some meaningful feedback instead of just displaying NaN (not a number). You can define an Error object that specifies off-limit conditions, what to do when those conditions occur, what do to do otherwise , andoptionallywhat to do in all cases.

The structure is try, catch, finally . You'll always have some code that you want to try to execute. You can include conditions (such as if statements) that throw errors. If any errors are thrown, the code is diverted to the catch you've defined. Finally, you can include code that will execute regardless of whether an error was encountered . Reread this paragraph after you see the actual code in Listing 11.5 because it might help explain the syntax.

Listing 11.5. Basic Try, Catch, Finally

 1   try { 2     if (Number(denominator_txt.text)<=0) { 3       throw new Error("Can't divide by zero"); 4     } 5     trace("okay"); 6   } catch (theError) { 7     trace(theError.message) 8   } finally { 9     trace("always"); 10  } 

Notice first that lines 1, 6, and 8 are aligned because, like an if-else statement, there are three parts . Actually, just like how the else is optional, you could forgo the finally by ending things at line 8 with a closing curly brace : } . Note that this entire listing would likely go inside an event (for instance, a button's onPress ). Mainly , it's line 5 that triggers when everything's okay. Think of line 5 as the else of the if statement in line 2. More specifically , line 5 will never be encountered if line 3's throw is reached. It's like return it skips the rest of the code. You could have several other if statements that throw different errors. You could even throw errors from within a loop. Suppose, for example, that you are looping through an array of usernames checking for any that match what the user typed (in which case you'd throw an error).

Any time an error is thrown, it gets redirected to line 6. You can think of line 6 as a function that waits to be invokedit just gets invoked whenever an error is thrown. The weird thing is that the passed argument "Can't divide by zero" gets stuffed inside the message property, a built-in property containing whatever parameter is sent when the error is thrown.

The trace() in line 9 triggers every timewith or without an error. This is just a place you can put code that gets triggered regardless.

First, you'll see a hard-wired try, catch, finally structure.

I guarantee you could pull off the same effect of the preceding code by using a more traditional (or familiar) approach. The Error object excels when you consolidate code and share exceptions and catches among several different places in your application. For this, you need to define a constructor function for each error you plan on using. By having several different parts of your code throwing the same error, you can later edit and refine that error to control all instances that throw it. In addition, you have an opportunity to use more than just the default message property. Listing 11.6 shows an applied example involving two input text fields ( top_txt and bottom_txt ) plus a dynamic text field for the result of dividing two numbers ( result_txt ).

Listing 11.6. Advanced Error Object

 1   function StringError(){ 2     this.errorString="need numbers"; 3     this.extra="you can't do math on words"; 4   } 5   function NumberError(){ 6     this.errorString="can't divide by 0"; 7     this.extra="it's just not allowed"; 8   } 9 10  my_btn.onPress = function() { 11    try { 12      // try 13      if (isNaN(top_txt.text)   isNaN(bottom_txt.text)) { 14        throw new StringError(); 15      } 16      if (Number(bottom_txt.text)<=0) { 17        throw new NumberError(); 18      } 19      //otherwise 20      result_txt.text = Number(top_txt.text)/Number(bottom_txt.text); 21 22    } catch (theError) { 23      result_txt.text =theError.errorString; 24      trace("extra info: "+ theError.extra); 25    } 26  }; 

The two constructor functions ( StringError() and NumberError()) have two properties that I made up: errorString and extra . Way down on lines 23 and 24, you can see I'm using errorString for what the user sees and extra for the trace() statement. I'm sure you can get more creative by modifying this code. Anywhere else in this application, you can throw either of these two errors. Keep in mind that you only throw inside the try portion. In addition, you need a catch defined uniquely for every try .

As mentioned previously, the Error object is a glorified if statement. Of course, it's much more than that. However, mainly you just specify what you want to happen, what the exceptions are, and how to handle exceptions.

[ LiB ]