User Guide

260 Handling Errors
Error handling strategies
As long as your application doesn’t encounter a problematic condition, it may still run
successfully if you don’t build error handling logic into your code. However, if you don’t
actively handle errors and your application does encounter a problem, your users will never
know why your application fails when it does.
There are different ways you can approach error handling in your application. The following
list summarizes the three major options for handling errors:
■ Use try..catch..finally statements. These will catch synchronous errors as they
occur. You can nest your statements into a hierarchy to catch exceptions at various levels of
code execution. For more information, see “Using try..catch..finally statements”
on page 261.
■ Create your own custom error objects. You can use the Error class to create your own
custom error objects to track specific operations in your application that are not covered
by built-in error types. Then you can use
try..catch..finally statements on your
custom error objects. For more information see “Creating custom error classes”
on page 266.
■ Write event listeners and handlers to respond to error events. By using this strategy, you
can create global error handlers that let you handle similar events without duplicating a lot
of code in
try..catch..finally blocks. You are also more likely to catch asynchronous
errors using this approach. For more information, see “Responding to error events and
status” on page 267.
Working with the debugger version of
Flash Player
Adobe provides developers with a special edition of the Flash Player to assist debugging
efforts. You obtain a copy of the debugger version of Flash Player when you install Adobe
Flash CS3 or Adobe Flex Builder 2.
There is a notable difference in how debugger version and the release version of Flash Player
indicate errors. The debugger version shows the error type (such as a generic Error, IOError,
or EOFError), error number, and a human-readable error message. The release version shows
only the error type and error number. For example, consider the following code:
try
{
tf.text = myByteArray.readBoolean();
}
catch (error:EOFError)