Question

There doesn’t seem to be a way to access stack traces for a released version of a Flex app running on a generic user’s non-debugger version of flash. I can still get access to the error number, but that’s just not good enough in some cases.

Was wondering if anyone has any tips on how to approach this. All I can think of is logging as many events as possible in some buffer and then dumping that to the server when a crash happens. I’ve implemented this and it’s ok but, unfortunately, adding logging all over the place doesn’t seem very practical if your code base is reasonably extensive. But maybe there’s a catch all way to log all sorts of stuff in some simple way that I have not thought of – some sort of centralized listener? Or maybe some other approach?

Will take any advice (although ideally skip the “you should test your app before you release it”?).

thank you!

Answer 1

There are not a lot of things you can do at this point, unfortunately. The obvious place to start would of course be trying to get the user to run the program on a debugger version of Flash Player. But if you can’t, and you need to find a way to “build in” runtime bug detection in a “catch-all” kind of way, there are only two immediate remedies I can think of:

1. Insert default logging messages at critical points in your application. This should be at a higher level of abstraction, possibly when creating or removing modules, or starting and finishing complex tasks. Ideally, logging should also be configurable, so that you can turn verbose output on or off when you need it, e.g. by changing a configuration file, or setting an environment variable during compilation – debugging code can slow down your application quite a bit, and you don’t want to have to add and remove individual trace statements every time you get a bug. If you’re an advanced ActionScript developer, you might even want to find a way to implement logging through metadata and/or custom namespaces – it’s a much cleaner approach.

2. Apply the catch-all approach to your entire application and trace the stack for every bug that is caught there. Perhaps this might not be much more explicit than what you already have, but at least you get to shut down the program cleanly (for example, by showing a message to the user) instead of just letting it crash.

It is unfortunate that you’ve already created your program with a “don’t tell me to test before I release” attitude – there are just not many things you can do “in retrospect”, except fire up the debugger and put in some extra hours. In fact, you should be testing every single line of code before you even write it… but I won’t get into that – TDD is usually something that needs way more explanation than a single answer.

Here’s a few simple things you can do to make your life easier in the future:

The biggest mistake people commonly make is not to let errors happen in the first place: If, for example, you have many null-checks in your application code:

if (myVar != null) doMyStuff(); // or
if (myVar == null) return;

this is usually used to prevent the dreaded #1009 error from showing up, it’s relatively effective, and at first glance it’s faster than using a try...catch block. But it will also obscure the root of the problem, or even let it go unnoticed: Your error might show up at a later point, where something else should have been initialized in doMyStuff(), or there might be places where you simply forgot to check.

The best strategy to become error free is:

• Never return or assign illegal values (e.g. don’t allow your functions to return null, assign initial values to all variables, etc.)

• Implement try...catch blocks at critical points in the application (whenever something can go wrong, essentially). These, then, send detailed log messages when errors are caught, and so you can easily spot the cause without having to resort to lengthy debugging sessions.

• Create self-validating objects. I like to have a verify() method, which is called before an object is initialized or added to the stage, check all the necessary dependencies – and throw an InstantiationException if anything is missing or has the wrong value.