Comments on: How are you doing global exception handling in Flex/Flash/AS3?

By: Flassari

Flassari — Wed, 23 Jun 2010 17:29:19 +0000

The new global error handler works like a charm. Flash Builder 4 doesn’t support it out of the box but it’s easy to get it to work, I wrote a post about it: http://flassari.is/2010/06/global-error-handling-with-flash-player-10-1/

Made my life so much easier, no more “can you install the debug player…”, just catch it and submit it automatically, or tell the user to copy it if submission fails.

By: CaioToOn!

CaioToOn! — Fri, 09 Oct 2009 16:51:18 +0000

Seems like this problem will be addressed on Flash Player 10.1

Look: http://labs.adobe.com/technologies/flashplayer10/features.html#developer

CaioToOn!

By: Global Exception Handling / Crash Reporting in Adobe AIR – Partially Solved?

Fri, 18 Sep 2009 11:24:02 +0000

[...] to Doug McCune’s excellent post on this topic, I saw that someone was Monkey Patching their Flex libraries to add some code to try and catch most [...]

By: Jörg

Jörg — Mon, 15 Jun 2009 17:55:11 +0000

Hi Doug,

I think I found a solution for the callLater RTE’s:
http://liquidnight.de/2009/06/15/global-exception-handling-in-flex/

By: Adrian

Adrian — Sat, 16 May 2009 02:40:36 +0000

Similar problem in the java world, check for null pointers, use try/catch in your code. But it doesn’t necessarily relate to Flash. The javascript approach is interesting but I would assume it would be rather flaky. If you have a FABridge or ExternalInterface call fail it wrecks havoc on all calls following that. Great question, but I am not sure if I am a fan of ‘polling’ to be part of the error handling process. But that is just an opinion.

By: Taylor

Taylor — Tue, 28 Apr 2009 01:13:11 +0000

Wow, I’m curious about Greg’s solution too. I am now one of the voters on the bug, and it burns me up that it still has a priority of “C” in their bug database.
We are porting our app from C# over to AIR. Since it’s so easy to do, our C# app has crash reporting. It’s got a few thousand desktop installations, and even though it’s pretty solid, I still get a crash report every day or so. And sometimes of course, we’ll release a beta that will “flood” me with useful crash reports and let me get it fixed ASAP. The idea of releasing commercial software without the ability to do this scares me. I can imagine the tech support emails I’ll be getting:
Me: “What happened?”
Them: “Well, the app started getting weird, and then silently froze.”
Me:

This evening I was hoping that the trace or error text was logged to stderr or stdout in hopes that I might be able to capture that and filter it. In my first tests for AIR, none of the text even goes to the std pipes, and even if it did, they don’t provide easy access to the std pipes. I was hoping that maybe Alchemy’s support(?) for pipes might help, but like I say, the text needs to go there first, and it looks like the release builds of your AIR app are pretty silent.

I also tried enumerating through flash.desktop.NativeApplication.nativeApplication.openedWindows when the main window got deactivated, in hopes that the error dialog would be one of them and that I could react appropriately. No dice.

For our beta testers (who are obviously more hardcore), I plan on using this cookbook trick to get it to pop up the error dialog: http://www.adobe.com/cfusion/communityengine/index.cfm?event=showdetails&postid=13206&loc=en_US&productid=4
Then, at the least, they’ll be able to email me with a stack track.
In fact, I might just leave this on for the app as a whole, considering I’d rather my users see _something_ than nothing at all.

By: Christophe

Christophe — Fri, 27 Feb 2009 18:25:30 +0000

Greg, how much work was this ? I’m thinking of compiling my own version of the Flex framework with a few try/catch statements added at strategic places (in particular to catch the DataGrid problems) but I’m not sure where to start. Can you share a bit more details ?

By: Greg

Greg — Sun, 22 Feb 2009 12:50:55 +0000

We created our own version of the mx:application class and also created our own layoutmanager class that either extends or copies the code from the mx classes. then in one function (callbacklater) in the layout manager we added a try catch block around that call because 90% of all errors that happen because of things in the flex framework can be caught here, especially the ones you cant trap with a try catch cause they are async. All the other errors we use our own try catch blocks in code. But it was the errors in the flex framework that were causing us the biggest headaches. Now we catch virtually all errors with 1 try catch statement.

It is not an easy thing to implement and might not be possible for some. But it would be an easy fix for the flex team to implement in the framework with little overhead. sure it does not catch every error, but gets the ones you cant try/catch yourself

By: judah

judah — Fri, 20 Feb 2009 02:17:54 +0000

IDK. You could test it like this:

At startup create a callback function that javascript can call.
Set a timeout in javascript that calls that flash callback function on a set interval (like once a second)
Throw an error on purpose
Check if js messages are still getting through
i think the flash player team might best be able to answer your question

you could also extend the error class or monkey patch it to make a call to javascript when an exception is thrown. don’t know if it’s possible to work with the error class. i also heard that there is a way to get the stack trace when encountering an error. just throwing ideas out there.

By: Deepa Subramaniam

Deepa Subramaniam — Tue, 17 Feb 2009 06:00:51 +0000

Hey Co-Author, happy birthday!