Debugging Flash applications can often be thought of as a dark art, but with practice and a few techniques it can turned into a scientific exercise.
One of the key things when fixing errors to to be patient and take your time to do it properly. Before you start, it is worth considering side-stepping the error by fixing it the hard way, eg removing the offending section and starting again and estimating how long such an approach would take. This is then a useful measure for the amount of time to spend debugging the ‘easy’ way. Take your time, and do it right first time.
I’ve found Steve McConnell’s Code Complete to be a big help in improving my coding as I moved from Flash design to focus more on development. Obviously, by following good development practices as you code, you will reduce the number of error that are made. However, sometimes you will have to debug an issue and the following broad approach is very useful:
* Reproduce the error
* Find its source
* Fix it
* Test it
Repeat the Error
Reproducing the error is the first step in fixing the code. Given Flash’s very nature this can often be a series of actions and events. You are trying to avoid guesswork so it is very useful to make notes on the steps taken to repeat the error. take you time to ensure that you understand the problem.
Once you can reliably repeat the error, make a copy of the code. You’ll need this later once you’ve made a dozen changes and forgotten exactly what you modified. You can then ‘diff’ the two copies to see what has changed.
Find the Error
The next step is to figure out why it is happening. I find it useful to start by add trace statements in the code to track the flow of data. Depending on the nature of the error, it is also useful to trace out specific variables, such as event information and error codes. The aim is to come up with a very narrow test case that triggers the error, but don’t expect to do this on the first attempt. It is usually the case of trying an initial idea, testing it out, reviewing the results and then repeating the process. Remember that not proving your idea can be just as useful in helping identify the issue. Also try to reproduce the error in different ways.
By working through the tracing data in a methodical way, you can narrow down the suspicious region in the code. Good places to look are classes that have had defects before and areas of code that have recently been changed. Another useful technique is “confessional debugging”: explaining the issue to someone else. In order to explain it, you have to go through the analytic process and it can help you solve the problem yourself.
Having identified the offending block of code, a useful technique is to use a binary search ( i.e. commenting out half the code at a time to see where the error is.) to further identify what exactly is causing the error.
Compiler Errors:
As3 compile errors can often be misleading eg the classic Error # 1046
1046: Type was not found or was not a compile-time constant:
which can mean a missing import statement or a symbol on stage with an instance name that is the same as a class name. It is worth noting that AS3 compilers can be funny when detecting multiple errors. Don’t worry if you get a page full of errors – fix the first one and then re-compile the code.
That said, it is worth turning on Strict and Warning Mode in the compiler and treating any warning as errors.
Fix the Issue
Remember to fix the actual cause of the error and not the result: treating the problem and not it’s symptoms. Fixing the symptoms is making the code worse. It is also wise to tread lightly when going through code – only change the code for a good reason.
Don’t be tempted to refactor as you go through – make one change at a time and test it. Changes are tricky enough on their own and you want to be sure that the change you made actually fixed the issue (if not then remember to remove it)
Finally once you are sure that the issue is fixed, then ‘diff’ the new version with the old to check that you haven’t added any unnecessary code. It is also worth checking the program for any similar types of errors in other places.
Next stop vector graphics…
