# Quick Tip: How to Debug an AS3 Error #2044

This post is part of a series called How to Fix Bugs in Flash.
Quick Tip: How to Debug an AS3 Error #1063

In this Quick Tip, we’ll take on run-time Error 2044, the un-handled IO error. It’s actually very simple, but it plagues even experienced developers, so we’ll go in-depth and turn everyone here into IO error ninjas.

## Step 1: Setting up the Problem

Let’s start by setting up some code in a Flash file that produces error 2044. Create a new AS3 Flash file, and enter this code into the Script panel:

Go ahead and run the SWF, and you should see this error:

You will see the same error, with a slight variation if we just change Loader to URLLoader, as in below:

You should see something like this, only with the file path reflecting your environment:

## Step 2: The Accused

As you might be able to surmise from the fact that Error 2044 crops up with Loader and URLLoader in use, this error has something to do with the loading of external files.

In fact, the error has something to do with the failure to load an external file. As the fake URL in my code snippets would suggest, the file we are trying to load is having a problem of some sort. Most likely it’s a case of the file being unreachable; this might simply be a mis-spelled URL, or a URL being created dynamically resulting in a bad location, or because the server or network is down at the moment.

However, Error 2044 is not accusing you loading a bad file. That’s going to happen. We can’t control the network, so a load failure is bound to happen at some point. Error 2044 is accusing you of not being prepared for when that happens.

## Step 3: Good Boy Scouts

Both Loader and URLLoader are event dispatchers, as you should know from working with them. You need to utilize the Event.COMPLETE event in order to know when a load is ready for you to work with it. If you’re reading this, though, you might not realize that these loading classes also dispatch other events, notably the IOErrorEvent.IO_ERROR event.

When a Loader or URLLoader encounters a failure, such as described in the previous step, it will dispatch an IOErrorEvent.IO_ERROR event. This is a specialized event for cases such as this. It carries a text property that describes the nature of the error, as seen in the errors we created in the first step; both code snippets produced Error 2044, but the text of each was different (even though it was semantically the same).

Unlike most events, though, when IOErrorEvents are dispatched, the dispatcher checks for the existence of at least one event listener. If it doesn’t find any, it throws the un-handled IO error.

So the solution is simple: simply add a listener for the IOErrorEvent.IO_ERROR event to your loader(s). Even if the listener doesn’t do anything, it will at least suppress the Error 2044, by virtue of merely existing.

Remember that you add events to the contentLoaderInfo property of Loader objects, not to the Loader directly:

However, you should be better prepared than this, like a boy scout; you would ideally determine what an appropriate action to take would be, then start that action in the event handler function. You might decide to load an “image not found” image or a default XML file instead. You might present an alert to the user notifying them that a required resource could not be loaded, and should try again later. Perhaps you also disable parts of your SWF because the required data couldn’t be loaded. You might even fire off a message to a server-side log with details, so that you can look into the situation.

## That Is All

As I mentioned, this one is pretty easy, really. It’s just a matter of getting in the habit of adding that event handler in the first place, so that you never see Error 2044 again. It won’t prevent resource loading from failing, but it can let you degrade gracefully and recover from the failure as best as you are able.

Thanks for reading. I’ll see you again shortly in another Debug Quick Tip.