Throughout this book, we’ve encountered plenty of compile-time errors—errors reported in the Output panel when a movie is exported. If a compile-time error occurs in an ActionScript 2.0 program, compilation fails and Flash won’t generate a .swf file to execute. But not all ActionScript errors occur at compile time. Some errors don’t occur until runtime, and they may not cause the program to fail completely. For example, suppose we attempt to load an XML file from disk, but the file is not found. If the movie is running in Test Movie mode, the failed load causes the Output panel to display an error message—but the movie continues to run. The following code demonstrates:

// If the specified file doesn’t exist…
var xmlDoc:XML = new XML( );
xmlDoc.load(“http://www.somenonexistentsite.com/someNonExistentFile.xml”);

// …the Output panel displays:
Error opening URL
“http://www.somenonexistentsite.com/someNonExistentFile.xml”

In an ideal world, we’d like to be able to recover from nonfatal error conditions such as a file-not-found. We’d like to tell the user there was a problem loading the file and perhaps display the problematic filename.

Unfortunately, in ActionScript there are precious few built-in runtime errors and, what’s worse, there’s no standard error-handling mechanism for dealing with the errors that do occur at runtime—at least, not for the errors that are generated by ActionScript itself. Most errors in ActionScript occur in the form of custom error codes and return values. For example, a method might return the value -1, false, or nullto indicate that some operation failed. This requires us to write different, individualized code for each kind of error generated by ActionScript. Read more…

• Exception Handling with BlazeDS and Flex
• Handling Java Exceptions in Flex application