Another Debug/Trace Class

This topic has been discussed many times in the Blog world, but I just wanted to contribute my new approach to debugging complex Flash Applications.

After working on the SNL Merger Model application for 8 months, I realized I needed a more robust method for tracing and debugging. The application was huge, and it was all developed in Flash not Flex. Compile times could often surpass 2 minutes, and that made it really frustrating when debugging small glitches.

More than that, if you are a fan of using trace statements, many of you know that as an application grows, it can become unweildly to manage them unless you keep them in context with the process that creates them.

So at the end of the day, I wanted to force myself to behave as a developer, and do the right thing. I designed a simple little class that we use frequently to debug our work at Teknision.

Suprisingly I called it:

com.teknision.debug.TraceManager;

but in it's simplicity it is very useful. The point of it was just to get our whole team thinking on the same wavelength so that when we hand work to each other, we can easily pick up on certain parts without having to study the whole project.

Here is how we use it in Actionscript:

trace(TraceManager.get().getThread("Application").getThread("init").getThread("loadConfig").trace("config file loaded"));

the output from this in the trace window is the following:


201:Application.init.loadConfig{ config file loaded}


The first part is the timer count in which the line executed, and the rest is a path that puts the trace statement in context to your work. Note that using this alot in an application will add processor overhead, but in most ways it is really worth it.

Note that the whole statement is held within the trace() function. This may be a technique used by many, but it is a way to make sure that you can easily eliminate this logic when you deploy production work. The fact that it is all executed in the trace() statement eliminates it on compile if "Omit Trace Actions" is turned on.

As we started using this, I have found that our team has begun to think more alike, and work is easier than ever to pass around. We even built a desktop app to recieve the traces remotely and allow threads to be filtered. This makes focusing on certain pieces of a system very easy.

[update]: thanks Stace

Truly one of the best things about it, is that it exposes application bootstrapping. At a glance I can see the log of everything my application is doing as it runs. Debugging using it is great, but also, another developer can really get on board much faster when observing this output.