Game Development Reference
In-Depth Information
that extend from it, such as ReferenceError or ArgumentError.
These subclasses give you more detailed information about what
went wrong. There are two main kinds or errors you
ll run into
during development.
The first are compile-time errors, which crop up when you go to
you know immediately that you did something flat-out wrong .The
SWF won
re forced to go
back and fix them. The most common errors are typographic:
mistyped variable names, assigningthewrongtypeofvaluetoa
variable, and calling a method that doesn
t exist. While they can be
annoying if there are many of them, it
about problems up front and fix them.
The other kind is a runtime error, which occurs while your SWF
is running. These are equally helpful, but they have to be discov-
ered and are most likely to crop up during testing. They
ll only
occur when you run the piece of code with the problem in it. The
other trick with runtime errors is that they
re not always mistakes,
per se. Sometimes, an error occurs when certain events are dis-
patched and nothing is listening to them. In this case, the error
acts as a notification that something went wrong and that you need
to account for the scenario in which it took place.
Regardless of the type, errors should always be handled. There
are a couple of ways to fix errors. Most of the time, the error is the
result of a coding mistake or omission. However, sometimes an
error can occur because a piece of functionality has other depen-
dencies, like external files, which are not available during develop-
ment. In this case, you can prevent the errors from bringing the
rest of your code to a halt by catching them.
try, catch, finally
If you want to trap an error and keep it from halting the rest of
your code, you should wrap the code inside what a try statement
try {
If an error occurs inside of a try block, it will attempt to be
caught by an adjacent catch block.
try {
} catch (error:Error) {
Search Nedrilad ::

Custom Search