Coming from ColdFusion, the concept of a debugging toolset was a little foreign to me. For you non-CF folk, prior to CF8, ColdFusion's built-in debugging features were little more than a Java stack trace and a souped up variables trace, affectionately termed cfdump. Jumping from CF to AS3 can be a tricky transition, having to deal with both compiler and runtime errors, not to mention slightly cryptic error messages "VerifyError: Error #1107: The ABC data is corrupt, attempt to read out of bounds". Now that I have a number of AIR applications under my belt, I thought it might be useful to revisit some of the Actionscript debugging basics that helped me get here (beta can be painful sometimes).

trace()

Trace is perhaps the first debugging method you learn in actionscript or MXML. It writes out a string representation of any AS Object or property to the debugging console during runtime. Here is a simple example:

var myObject:Object = { label : 'hello world' }; trace( myObject.label );

trace is one of the cornerstone approaches to Actionscript debugging but it can get much more useful than the previous example. I'll come back to it in a moment.

Strong Typing

Let the compiler go to work for you. The compiler provides feedback based on the metadata located in your MXML and Actionscript Classes. More specifically it introspects over Object Types, Interfaces, and additional compiler metadata looking for syntax and basic logic errors. To get the most out of the compiler provide an Object Type or Interface for all of your Class members, local variables, function arguments and return variables. Be sure to check out the metadata tags available in Flex 2 (http://livedocs.adobe.com/flex/201/html/metadata_141_04.html). If you're using Flex Builder, all this metadata will contribute to the already stellar code completion built into the IDE.

(More Code Completion) + (Reduced Runtime Debugging) = Flex Rockstar

toString()

It always amazes me how many developers leave the most productive function out of their AS classes. Of course, I'm referring to the toString() method. The toString method is implemented on the base Object Class in Actionscript, so every Class has a public toString method whether you realize it or not. However, the Object.toString() method isn't particularly useful in most debugging situations. The basic implementation return a string containing "object" and the name of the object's Class that its called on. So take "MyClass" as an example Class, the toString method would return "object MyClass". Not exactly a pair of brass knuckles when you're in a full-on fist fight with your Flex app; however, if you override the toString method with some custom logic you can add considerable power to the trace function. Now you'll never have to write an eloborate trace statement again.

trace( obj.a +" <-- that's a || :() || here's b -->" + obj.b)

is replaced with

trace( obj );

Breakpoints

Breakpoints are clutch when you encounter a runtime error and you're not sure what the cause is. The debugger provides a list of all the available variables in the current scope so you don't necessary need to know who the culprit is, just where the problem might occur. A couple additional reasons to use breakpoints is you can add them during runtime (on the fly) without having to recompile the application. When you start dealing with larger Flex applications, compile time can be a real productivity killer so that's when you should keep breakpoints in mind.

Pausing a Thread

In the same vein as breakpoints, you can pause a Flex application at anytime from the debug menu. I don't used this feature very often but it can come in handy if you're not sure where/how your code is currently executing (logic loops etc).

Errors

You should be tossing errors around like Drew Brees throws up interceptions (uh oh, i think that analogy went horribly arye). At the end of the day, errors are the enemy but not necessarily during the debugging process. Be explicit with your error detection early on in development and then go back and add in handlers. Once you've found the source of the problem, you can use the methods mentioned above to formulate a solution.

Is that it? Definitely not, but it'll get you headed in the right direction. You need to have strong fundamentals (like many things) before you can jump into development methodogies, patterns, and testing frameworks.

If you are looking for more info, check these links:

** Adobe Debugging Tutorial

http://learn.adobe.com/wiki/display/Flex/Debugging+tutorial

** Flex Builder Memory Profiler

http://livedocs.adobe.com/labs/flex3/html/profiler_1.html

** ASUnit (Actionscript Automated Testing Framework)

http://www.asunit.com/

Cheers,

Todd "People will go BS over my Title" Cullen

Pier Evangelist