In ActionScript 2.0, if a method throws an exception, it's up to the programmer to know about it in advance and handle it appropriately. Nothing you write in your code can force you or anyone else to handle an exception. The compiler will make no complaints if an exception is not handled. (Of course, an uncaught exception can cause code to be aborted at runtime, as discussed earlier under Section 10.3.1)

Exceptions are, hence, harder to work with in ActionScript than in languages that support compile-time errors for uncaught exceptions. In Java, for example, an exception can be either checked (a compile-time error occurs if the exception is not handled) or unchecked (no compile-time error occurs if the exception is not handled).

In Java, the declaration for a method that throws a checked exception explicitly includes the exception in the method header. Here's a Java method declaration that explicitly states the type of exception the method can throw (in this case the method can throw exceptions of type IOException):

public void someMethod( ) throws IOException {
}

Upon reading the preceding method declaration, the programmer immediately knows she must handle IOExceptions when invoking the method. If the programmer invokes the method without catching or rethrowing the exception, Java will produce an error and the program will not compile. This strictness forces programmers to dutifully deal with exceptions, leading to less time debugging exception-related errors. ActionScript doesn't support the throws clause in method declarations.

We saw earlier that Flash doesn't throw an exception when a developer attempts an illegal operation, such as dividing by zero. Neither the class library built into the Flash Player nor the Flash MX 2004 v2 components throw exceptions. The only exceptions generated in Flash are those thrown by custom-written programs. This exception-less environment leads to two problems. First, Flash must relay all error information to the programmer using unwieldy error codes or return values. Second (and much worse), Flash often fails silently when a runtime error occurs. Silent errors are very difficult to track down. In the future, as versions of the Flash Player that support exception handling are adopted, it is likely that ActionScript will generate more built-in exceptions.

In programming languages that do not support exceptions, programmers often use error codes to represent error conditions. That is, if a method or function encounters an error, it returns a message or code describing the problem and expects the caller to know how to interpret that code. While more awkward than exceptions in many situations, this older, grassroots style of signaling an error in a program is actually faster than throwing an exception.

For this reason, even with exceptions supported in ActionScript, returned error codes are sometimes still a good technique for error handling, primarily in situations that are highly performance intensive. Both exception handling and error codes are useful and can be used together in different parts of the same program, depending upon the performance needs of different parts of your code.

But before you get excited about speed improvements and swear off exceptions for life, be aware that in most programs, no human-perceivable improvement in speed results from using error codes instead of exceptions. But in situations in which every last bit of performance makes a difference to the program, it may be necessary to forego exceptions in favor of faster error codes.

The speed test in Example 10-5 compares the amount of time it takes to throw and catch 1000 exceptions with the amount of time it takes to handle a return value of false 1000 times. On average, throwing an exception takes approximately three times as long as handling the return value. However, on my aging Pentium III 700 MHz Windows test machine, the entire process of throwing 1000 exceptions took a mere 187 milliseconds (compared to 57 milliseconds to handle the false return values). In most programs, this potential 130-millisecond savings will be irrelevant. In the vast majority of cases, the benefits of clean exception-based code far outweigh the performance costs.

// The class file, in ExceptionPerformanceTest.as.
class ExceptionPerformanceTest {
  public function test1 ( ):Void {
    throw new CustomException( );
  }

  public function test2 ( ):Boolean {
    return false;
  }
}

// The exception class in CustomException.as.
class CustomException extends Error {
  public var message:String = "This is the error message.";
}

// The test code, in ExceptionPerformanceTest.fla.
var ept:ExceptionPerformanceTest = new ExceptionPerformanceTest( );

var count1:Number = 0;
var count2:Number = 0;

var start1:Number = getTimer( );
for (var i:Number = 0; i < 1000; i++) {
  try {
    ept.test1( );
  } catch (e:Error) {
    count1++;
  }
} 
var elapsed1 = getTimer( ) - start1;

var start2:Number = getTimer( );
for (var i:Number = 0; i < 1000; i++) {
  if (!ept.test2( )) {
    count2++;
  }
}
var elapsed2 = getTimer( ) - start2;

trace(elapsed1);  // On my Pentium III 700, displays: 187
trace(elapsed2);  // On my Pentium III 700, displays: 57