Global Exception or Error Handling in Flex

Xavi Beumala — Thu, 13 May 2010 09:08:52 +0000

In this post I explain how you can catch unhandled exceptions or errors globally in a declarative mxml-based way using the [Mixin] flex-specific metadata tag.

Starting on FP 10.1 and AIR 2.0 you can capture unhandled exceptions or errors globally. Although you can use these new APIs you should always take care of the exceptions where they happen and use this technique only as a diagnosing or logging help or for async exceptions that you can’t really control in any other way.

You might also be interested in these 2 other topics:

The new API works like:

loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR, onUncaughtError);

private function onUncaughtError(e:UncaughtErrorEvent):void
{
// Do something with your error.
}

Christian Cantrell explains some more details on the APIs. You can find further information in the documentation as well.

When working with Flex, and adding the UncaughtErrorEvent.UNCAUGHT_ERROR listener to the loaderInfo object make sure you do it after FlexEvent.APPLICATION_COMPLETE event has been triggered, otherwise you’ll get an “Error #1009: Cannot access a property or method of a null object reference”

To prevent all this required glue code and avoid unnecessary configuration code (that ends up cluttering the main application Class) I’ve created a GlobalExceptionHandler component that abstracts developers a little bit from these sort of problems. The implementation isn’t tighted to the APPLICATION_COMPLETE event, instead it uses the [Mixin] metadata tag. On top of that you can use it declaratively:

version="1.0" encoding="utf-8"?>
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
xmlns:logging="com.adobe.ac.logging.*">

>
preventDefault="true">
/>
/>
>
>
>

You can download the code along with a sample project here. The code for GlobalExceptionHandler:

package com.adobe.ac.logging
{
import flash.display.LoaderInfo;
import flash.events.UncaughtErrorEvent;

import mx.managers.ISystemManager;

[Mixin]
[DefaultProperty("handlerActions")]
public class GlobalExceptionHandler
{
private static var loaderInfo:LoaderInfo;

[ArrayElementType("com.adobe.ac.logging.GlobalExceptionHandlerAction")]
public var handlerActions:Array;

public var preventDefault:Boolean;

public static function init(sm:ISystemManager):void
{
loaderInfo = sm.loaderInfo;
}

public function GlobalExceptionHandler()
{
loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR,
uncaughtErrorHandler);
}

private function uncaughtErrorHandler(event:UncaughtErrorEvent):void
{
for each (var action:GlobalExceptionHandlerAction in handlerActions)
{
action.handle(event.error);
}

if (preventDefault == true)
{
event.preventDefault();
}
}
}
}

The code for LogHandlerAction:

package com.adobe.ac.logging
{
import mx.logging.ILogger;
import mx.logging.Log;

public class LogHandlerAction implements GlobalExceptionHandlerAction
{
private static const LOG:ILogger = Log.getLogger("UncaughtException");

public function handle(error:Object):void
{
if (error is Error)
{
var errorObj:Error = error as Error;

LOG.error("{0}. {1}\n {2}",
errorObj.errorID,
errorObj.message,
errorObj.getStackTrace());
}
}
}
}

Debugging production ready AIR applications

Xavi Beumala — Sun, 16 Aug 2009 02:19:49 +0000

One of the biggest problems around testing installed AIR applications is that testers can’t see when a runtime exception is triggered. Lots of times the symptom of a problem will be something completely different to the real cause and developers will have to spend much more time trying to figure out what was the root cause of the problem. Even though you have a good logging policy if there’s an uncaught exception there’s not too much you can do.

Here are some techniques I’ve came across to make testing less painful for everybody.

The debug flag way

One thing I’ve been thinking for a while is that there are not two different versions of the AIR runtime; one with debugging enabled and the other without it (the way Flash Player has). This means that there might be a way to enable and disable debugging in the same runtime. This would allow, at least in some controlled environments, to see Runtime Exceptions and make everybody’s life easier. At least until we have global error handling implemented directly on AIR or Flash Player. Yes, I agree, It’s unbelievable that on its 10th version we still are not able to capture global exceptions: FP-444 and FP-1499

Using Procmon I realized that when an AIR application is launched it tries to read a file in {INSTALLATION_FOLDER}/META-INF/AIR/debug. See the screenshot. What surprised me was the result “NAME NOT FOUND”. Basically the file didn’t exist in the app I was playing with. After some more trial / error, yes, you’re right, this is the flag that switches on and off debugging capabilities.

If an AIR application is launched and an empty file with name debug is found in {INSTALLATION_FOLDER}/META-INF/AIR/debug then, any runtime exception will be displayed in a system modal window! In OS the path for this file will be {APPLICATION_FOLDER}.app/Contents/Resources/META-INF/AIR/debug

So if testers (or users during the earlier versions of your app) are using your application, make sure they create the debug file and attach any stack trace they see to their bug reports.

The adl way

This is not as easy as the previous solution but it gives the testers more options.

Once installed, an AIR application, is not more than the swf file produced from FB, its application descriptor and a native launcher. Given that we have access to the main application swf file and its corresponding descriptor we can use ADL to launch the installed application instead of the native launcher.

Here’s how:

1. Installed the SDK you want to use from http://opensource.adobe.com/wiki/display/flexsdk/Downloads
2. Uncompress the zip in the location you prefer. I’ll refer to this folder as {FLEX_HOME}

In Windows
3. Right click on “My Computer” > Properties
4. Go to “Advanced” tab
5. Click in the option “Environment Variables”
6. In the “System variables” find the “Path” definition and add this to it (double clicking on it): “;{FLEX_HOME}/bin”
7. Make sure your replace {FLEX_HOME} with the path to the folder where you’ve uncompressed the SDK

In OS X
3. Open a terminal
4. Execute this command: open ~/.bash_profile
5. Add the following line to the opened file:
PATH=${PATH}:{FLEX_HOME}/bin
6. Make sure your replace {FLEX_HOME} with the path to the folder where you’ve uncompressed the SDK

In Linux
3. Open a terminal
4. Edit your profile file ~/.profile
5. Add the line: export PATH=$PATH:$FLEX_HOME

Then to launch the application you will have to:

In Windows
1. Open a command line window. Start > “Run …” > cmd
2. Navigate to the folder where the application is installed: cd “Program Files”/MyApp
3. Execute this command: adl META-INF/AIR/application.xml .
4. Don’t forget the dot at the end of the command

In OS X and Linux
1. Open a terminal
2. Navigate to the folder where the application is installed: cd /soft/testAirApp.app/Contents/Resources where testAirApp is the name of your application
3. Execute the following command: adl META-INF/AIR/application.xml .
4. Don’t forget the dot at the end of the command

If during the execution process there’s an exception, ADL will show it.

rialvalue.com » air

Global Exception or Error Handling in Flex

Debugging production ready AIR applications

The debug flag way

The adl way