go to 'Preloading'

go to next page

Error Handling

I migrated to Actionscript from C++, so I was immediately attracted to try-catch as a general error-handling mechanism. Unfortunately, its function was well short of expectations, so I tend to use events to manage errors in an application. All errors eventually work their way up to the Controller. The Controller instructs the View to display the error message. In production, many applications communicate with a server, so it is helpful to log the error to assist in debugging.

Only a single error message is recorded in the current code base. In a production application, it is useful to maintain two messages. The first message is a simple indication to the viewer that an error has occured. The type and severity of the error may also be reported. Depending on the type of error, the viewer may decide to take action such as close the application, restart, login again, etc.

More detailed information, including class and method where the error occurred is maintained in a second message. This more detailed message can be logged to a server for further investigation and debugging.

The current code has a 'hook' in the Controller for logging. This is discussed in more detail in a later section.

Bubbling

Suppose that class A is the Controller. Class A contains a reference to Class B, which contains a reference to Class C. Class B calls a method of C with an incorrect argument. Class C responds by dispatching an error event.

In AS 3, events bubble, i.e. work their way up the call stack until a handler is found. Since the Controller is ultimately responsible for processing the error, it would be convenient to dispatch an event in a low-level AS 2 class and have it automatically bubble up to the Controller.

Sounds good except that AS 2 events do not support bubbling. Well, that's not entirely accurate. Ralf Bokelberg has posted an excellent tutorial on how to implement event bubbling in AS 2. Peter Elst has also posted an example based on this technique.

There are some instances where you may wish to consider not bubbling events, even though it is possible. Consider the above example. Suppose the offending method in class C could be called from other sections of code. In some applications, it might be called only from class B, but class B could be in one of several 'states' when calling C's method. The first questions asked during debugging might be 'where was C's method called from' or 'what was the class B state when the error occured?'

If an error event is automatically bubbled, none of this information is recorded. Although it takes longer to code, one alternative is to handle C's error event in class B and then add information on the state of B in the error message that is dispatched to class A. This additional information could be invaluable in debugging.

For tutorial purposes, the latter technique is employed in the portfolio viewer.

Quick Error Display - SimpleAlert Class

In the early stages of development, errors occur frequently. In order to to avoid debugging time bombs, it is helpful to display errors as soon as they are detected. In a large application, an artist is responsible for designing the production error screen. There is no guarantee exactly when those graphics might be available.

I personally prefer a 'quick and dirty' error screen that can be used to popup error messages. An Alert component is handy, but the V2 Alert is quite bloated and some third-party component libraries do not contain Alerts. For quick and simple error message display, I often use a SimpleAlert class. This is nothing more than a modal overlay built out of a TextArea and Button component.

The modal overlay is implemented with a Modal class. The Modal class creates an empty MovieClip with the necessary properties to simulate modality. The drawing API is used to create a rectangle with the same dimensions as the Stage. The Modal class accepts color and alpha values as inputs. These are used to adjust the color and transparency of the overlay. Thse two properties can be used to make the interface appear to be 'greyed out' when the SimpleAlert overlay is displayed.

The SimpleAlert contains two buttons - 'Cancel' and 'OK'. The class dispatches an event when either button is clicked. With some styling, the SimpleAlert might actually be production-worthy. Even if you never use it, you may find the Modal class handy. I generally use SimpleAlert for modal error display during the early stages of a project, at least until the production error screen graphics are delivered.

SimpleAlert and Modal are included with the current code in the event you might find them useful for other projects. Error display for the current code is handled with SimpleAlert.

go to 'Preloading'

go to next page