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.

17 Responses to Global Error Handling in AIR 2.0 and Flash 10.1

  1. George Scott says:

    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:https://bugs.adobe.com/jira/browse/FP-644

  2. Brian Sexton says:

    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.

  3. Hell yeah, love it. This is huge for large scale deployment where anything (and usually everything) can go wrong.

  4. Christian Cantrell says:

    Brian,But wouldn’t you at least like to show the user an error? Failing silently seems like the worst possible option.

  5. Brian Sexton says:

    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”.

  6. Christian Cantrell says:

    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

  7. How might this work in JS AIR applications?

  8. Xavi Beumala says:

    if you don’t want to rely on applicationComplete event you could use the [Mixin] metadata tag. More info on the technique here http://www.rialvalue.com/blog/2010/05/13/global-exception-or-error-handling-in-flex/

  9. RDS says:

    but the flex sdk doesnt show the uncaught error event in the event directory??how to do that

  10. Albert says:

    So many months waiting for this feature and today I discover i can get no stack traces in the non-debug player.This is so disappointing, an error without stacktraces is not very useful for logging purposes.

  11. Error #1014: Class flash.events::UncaughtErrorEvent could not be found.

  12. Tom says:

    For people needing stack traces.. did you consider rolling your own?

  13. Daniel Leahy says:

    This only seems to work for WindowedApplication

    and not for Application

    Title suggests it is for AIR and Flash, can you provide a version that works with Flash and not just AIR

    You get Error 1046 Type not found UncaughtErrorEvent if you use the above with Flash.

    I am currently looking for a solution to use UncaughtErrorEvent in Flash, with all the examples i see on the net i haven’t found one that works yet.

    • Amit says:

      Hi Daniel,
      I was wondering, Have you found any solution for a web application as you stated in your question or any other workaround?
      If so, it will be great if you could share it here.
      Thanks in advance!

  14. jacob says:

    Hi, is there any progress on the getStackTrace() used with this global error handling?
    It would be very nice to know in witch file and on witch line the error occurred.
    I now save this errors in a log.txt so users of my application can mail me the log file when there is a problem.. Still it’s not very easy to reproduce the error in a large application.

    Greets J.

  15. Marcus Fritze says:

    Any news about the getStackTrace(). It would be very useful for application development to know where the bug is.

  16. Thijs says:

    I have an iOS AIR app that throws an error only in the release version, when debugging the app using Flash Builder or installed as a desktop application it doesn’t throw any errors (argh!).

    I registered the global error handler and display a popup when an uncaught error is detected. The problem is that the only info I can retrieve is “TypeError error id 2007” but not where this error occurred since getStackTrace isn’t available. So now I have no way of knowing where the error occurs, and since it’s only happening on the iPad, I’m stuck.

    Do I really have to make some custom ‘breakpoints’, and use a Socket or something to log to an external server what line approximately was hit before this unknown error occurred?!