- try/catch to capture all errors inside my class(es)
- never use throw again. Instead, dispatch an error event that abstracts all errors into one event.
- have that error event include the reason why something broke

If you code ActionScript, you understand events. Events are optional, just like RuntimeExceptions (unchecked exceptions) in Java. So… seems good enough for me! Heck, even HTTPService does this via the fault event. No exceptions there… good enough for Flex, good enough for me.

The strangest thing to me with exceptions is something small, which is that binding swallows a few exception (see BindingUtil). That’s caught me a few times.

Rather than returning false, or trying the call anyway (knowing it’s going to fail), I clean up the mess (remove event listeners from the URLLoader, delete it) and then throw an exception. The exception for typical messages is just an error:

throw new Error ( “Cannot pass a null value for a UUID.”);

For some of the API stuff I’m doing, however, I feel like, based on what I read from the Java articles, encapsulate it into a custom event. I do the same as the above for the custom error:

throw new APIError ( “Cannot pass a null value for a UUID.”);

For internal things, like bad data, errors returned from the database because it’s down, or just no internet connection, I’ll capture all 3 and put into a generic error:

var err:APIError = new APIError ( “Cannot retrieve data from the server.”);
err.rootCause = theIOError;
throw err;

That way, people using the API only have to do:

try
{
   api.getPeople ( “3xedrg5″ );
}
catch ( err : APIError )
{
   showErrorScreen();
}

This includes asyncronous ones:

api.addEventListener ( APIErrorEvent.ERROR, onAPIError );
function onAPIError ()
{
   showErrorScreen();
}

The generic ones help in debugging.

However, key thing to note, if I know that a simple operation will fail, say passing NaN to an addChild method, I wouldn’t catch that myself. The crackhead who passed the NaN should either inspect his/her own data, and/or try/catch for RangeError’s. The downside is, unlike Java, he has no clue he’ll even GET a RangeError because there is no “throws” like thing in Java. Part of me wants to encapsulate those as well; store the root cause in my custom error, and just throw an APIError.

The other part of me doesn’t want to allow bad data in, and then hide the true cause 1 level away. If you are passing in NaN’s, that’s the API user’s fault. I’m leaning more towards the custom exception, though, because I feel I can write better error messages than what the defaults imply. So, instead of:

var a:MovieClip = new MovieClip();
addChildAt(a, 20);

Causing:

RangeError: Error #2006: The supplied index is out of bounds.

In the API, it’d instead attempt to find a valid depth, and then throw:

APIError: “Cannot add a child to a depth of NaN. Put to depth 0 instead.”

The root cause is in there, and they can print out the stack trace if they so choose. Furthermore, the error gives more context.

:: shrugs :: I’m new at this, no hard and fast opinons yet.