« New AIR 2.0 API: URLRequest.idleTimeout | Main | Exhaustive List of Everything That's New in AIR 2.0 »
October 28, 2009
Global Error Handling in AIR 2.0 and Flash 10.1
One of the most popular feature announcements during my MAX presentation was global error handling (GEH). GEH lets you handle all uncaught errors (both synchronous errors and asynchronous error events) in one place in your code. Here's an example of how it will work:
<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" applicationComplete="onApplicationComplete();">
<mx:Script>
<![CDATA[
private function onApplicationComplete():void
{
loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR, onUncaughtError);
}
private function onUncaughtError(e:UncaughtErrorEvent):void
{
// Do something with your error.
if (e.error is Error)
{
var error:Error = e.error as Error;
trace(error.errorID, error.name, error.message);
}
else
{
var errorEvent:ErrorEvent = e.error as ErrorEvent;
trace(errorEvent.errorID);
}
}
private function onCauseError(e:MouseEvent):void
{
var foo:String = null;
try
{
trace(foo.length);
}
catch (e:TypeError)
{
trace("This error is caught.");
}
// Since this error isn't caught, it will cause the global error handler to fire.
trace(foo.length);
}
]]>
</mx:Script>
<mx:Button label="Cause TypeError" click="onCauseError(event);"/>
</mx:WindowedApplication>
Registering for uncaught errors is hugely convenient, but it doesn't entirely excuse developers from handling errors where they're most likely to happen. For instance, you should still always register for things like IOError events and other errors that are likely to happen at some point, and that you can usually recover from. But starting with AIR 2.0 (and FP 10.1), you will also be able to register globally for errors that you weren't able to anticipate, and handle them at least somewhat gracefully.
The big question is what you do once you've caught an unhandled error. That will probably depend on the application. Since it's likely that a function exited without executing all the way through, there's no telling what state your app will be in. The safest thing to do is probably to log the error, show a very contrite dialog box, and then exit the app (after all, if the error had been predictable and easy to recover from, you should have caught it explicitly). You might try sending the error message to your server, including instructions for emailing the log file to a support email address, or if it's an internal application, provide a telephone extension to call for someone to come take a look. It's entirely up to you. We provide the API, you provide the solution.
Posted by cantrell at October 28, 2009 10:46 AM
Comments
I'm very happy to see this feature finally being included in the next version of AIR and the Flash Player.
However, without stack traces in the non-debug versions of AIR and Flash, this feature will not be useful as a diagnostic tool which is the main purpose of this feature.
I hope that adobe will also address FP-644 in AIR 2.0 and FP 10.1 as well:
Posted by: George Scott at October 28, 2009 11:37 AM
I disagree that "you should still always register for things like IOError events and other errors that are likely to happen at some point, and that you can usually recover from" because there are times when it simply isn't useful to do anything in response to a data-loading failure. If you're not logging failures and the user doesn't need to see a special message (e.g., because default content is already in place) then you simply might not care. That's why there are so many empty catch blocks in ActionScript today.
Posted by: Brian Sexton at October 28, 2009 11:44 AM
Hell yeah, love it. This is huge for large scale deployment where anything (and usually everything) can go wrong.
Posted by: Sean Christmann at October 28, 2009 11:46 AM
Brian,
But wouldn't you at least like to show the user an error? Failing silently seems like the worst possible option.
Posted by: Christian Cantrell at October 28, 2009 12:09 PM
Not always. For example, consider an application that loads and displays externally-specified advertisements. If the application fails to load something for such an advertisement, do you really think the user will care in the slightest?
For another example, consider a game that communicates with a server frequently—such as one of the popular farming games on Facebook. If a request for an updated state fails and the requested information is minor, it may be preferable to ignore failures until a lack of updates is detected—a state which may be monitored elsewhere. To notify the user every time a minor communication fails in such an application might actually result in frequent errors and seem like pestering or worse, give users the impression that the application itself is particularly buggy.
As yet another example, consider a Twitter application or a feed reader. TweetDeck does display a small message in response to communication errors, but it may not be desirable to pester users over every failure of automatic updates.
And the list goes on. If you're making non-interactive kiosks (like the one in the west tower lobby that tends to break out of its demo and show operating system messages), you probably don't want users to see error messages for much of anything. If you have a lobby kiosk cycling through cars, houses, or whatever, you would probably prefer for that to be your exclusive message to your potential customers—NOT "Hey, our application just failed to do something".
Posted by: Brian Sexton at October 29, 2009 11:26 AM
George,
We did look at enabling getStackTrace() in AIR 2.0 for non-debug builds, but the additional runtime overhead was unacceptable. We need some time to get it to a point where it's not a step backwards in terms of performance. It's definitely on our radar!
Christian
Posted by: Christian Cantrell at October 29, 2009 12:50 PM
How might this work in JS AIR applications?
Posted by: andy matthews at October 29, 2009 1:30 PM
Use of this website signifies your agreement to the Terms of Use and Online Privacy Policy (updated 07-14-2009).