Joeflash’s Enigmacopaedia


Error #2044: Unhandled IOErrorEvent - Solution

Posted in ActionScript 3.0, Flex, Design Patterns, Flex 2 by Joeflash on the November 18th, 2007

This past September, a good friend and trusted colleague of mine David Stiller came to me with a puzzling debug message: the dreaded Error #2044. At the time I didn’t have much to tell him, until I encountered it myself a few weeks later. Now I just had to find an answer.

Unfortunately the Adobe LiveDocs runtime error listings are not particularly helpful in this regard. Judah’s blog post on the matter does give some additional info, but neither David or I had encountered this error because of a problem uploading a file, nor did the try-catch solution seem to fit in our case.

The solution at first glance seems simple: make sure that either the file the application is loading, uploading or the server-side script it is referencing, is actually there, and it is not corrupted. All of the above can result in a #2044 error.

But what if you want the error handled without the runtime debugger being in your face about it? In both David’s and my case, we wanted to ensure that if files referenced by application were not there or corrupted, that the user (i.e. QA person/developer) would get a nice alert popup instead of a runtime error — or worse, having the app fail silently.

You would expect that the following would handle the error:

  1. loaderXML.addEventListener(ErrorEvent.ERROR, handleError);
  2. ...
  3. private function handleError(evtObj:ErrorEvent):void
  4. {
  5.    // do something
  6. }

But that doesn’t work. As the error implies, you need to use the IOErrorEvent class, not the ErrorEvent class.

  1. loaderXML.addEventListener(IOErrorEvent.IO_ERROR, handleIOError);
  2. ...
  3. private function handleIOError(evtObj:IOErrorEvent):void
  4. {
  5.    // do something
  6. }

That works. But hang on, we’re not quite done. If you use a custom event bubbling scheme, as I had done in a custom MVC framework I built for a client…

  1. loaderXML.addEventListener(IOErrorEvent.IO_ERROR, handleIOError);
  2. ...
  3. protected function handleIOError(e:IOErrorEvent):void
  4. {
  5.    dispatchEvent(new IOErrorEvent(IOErrorEvent.IO_ERROR, false, false, IOErrorEvent(e).text));
  6.    trace(IOErrorEvent(e).text);
  7. }

… and you dispatch an IOErrorEvent.IO_ERROR event, you also need to handle it all the way up the chain… or you’ll get the same runtime debugger error.

Once all possible dispatches of that event were handled as it bubbled all the way up through my Services and my Controller classes, my View showed a nice Alert with the error text, no debugger crashes.

So the lesson here is: anywhere you load a file, access a script, or load or upload any data of any kind whatsoever, in order to build a robust application, you can’t just think about handling the ErrorEvent.ERROR event: you also need to account for the IOErrorEvent.IO_ERROR event as well, or your application will have holes in it which may let slip by the dreaded Error #2044.