13.2 Trapping Errors

Error handling and error trapping are big parts of debugging. After all, a bug is a programming error that hasn't been fixed or can't be fixed. But not all errors are bugs. An error may simply reflect an operational condition, such as an attempt to divide by zero. The error is not in the programming logic, but in the data. An error message is a developer's way of saying "This is a condition that we couldn't prevent, but this is what happened and this is what you should do." It is the responsibility of the developer to fix errors caused by bugs and to handle errors caused by bad data or adverse runtime conditions (such as a loss of the connection).

13.2.1 try/catch Blocks

The try/catch construct gives server-side service developers an easy way to trap errors where they occur. (See Section 6.5, which covers Server-Side ActionScript; Section 8.6; or the related ColdFusion tags, <cftry> and <cfcatch>, in Chapter 5.)

Remember, client-side ActionScript does not support try/catch constructs, so you should be diligent in handling possible error conditions in your Flash application.

To reiterate, the server-side try/catch construct works like this: the try block contains the code for which you want to trap any errors as it executes. You are saying "try to execute this code." If an error occurs, the catch block is executed. It can take whatever action is necessary to handle the error condition. For example, if the application is inserting data into a database, this might be as simple as not doing the insert. If the application is accessing a file, the catch block may have to close the open file and perform cleanup. Often, the catch block just passes an error message back to the user.

The main point of the catch block is that the application code handles the error, rather than allowing the language interpreter to throw an exception. Your code should handle errors in a way that allows the user to continue to work; otherwise, it should present an error message that makes sense to the user.

Some forms of try/catch blocks also have an optional finally block, which contains code to be executed whether or not an error occurs.

This is how it might look in practice:

function myFunction ( ) {
  try {
    // Do something here.
    // If there is an error, proceed to the catch block.
  } catch (e) {
    // Close files, do some cleanup, send an error message to the user, etc.
  } finally {
    // In either case, do this.
    return;
  }
}

The Flash Remoting adapter on the server also traps errors that can be handled in your client-side ActionScript.

The Flash Remoting adapter is, in effect, a large try/catch block around all of your server-side services. It handles any errors not handled by the server-side code. An error that occurs in a service on the server causes an onStatus event, rather than the onResult event, to be returned to your Flash movie.

You can implement an error-handling strategy that uses the best of both techniques: handling server errors from your ActionScript within the onStatus( ) methods of the calls to the service. You can accomplish this with the throw construct, which allows you to generate custom errors. The benefit is that you can trap the actual error, perform your cleanup, and then throw a custom error message back to the Flash movie. The technique of throwing custom errors is shown throughout the examples in Chapter 5, Chapter 6, Chapter 7, and Chapter 8.