Main Content
Debugging: Fixing your own errors
There are very few people in this world who can honestly say that they never make a mistake; very few programmers who haven't hit 2 instead of " once in a while. I mean, I'm making mistakes as I type this. People also forget stuff - getNextDepth() is not the correct function name as an example. That's why we here at Foundation Flash get quite a few emails every week, a percentage of which could be helped by understanding all of those error message that come up, I'm sure.
Over the next few weeks we will looking over errors in general, specific error messages and the just-in-case scenarios. For today though, we shall be talking about the first of these, and the types of error that could occur. There are three type in fact - compiler (or syntax) errors, runtime errors and logic errors.
Compiler / syntax errors
These are the errors that come up in that handy little 'Compiler Error' box, which will present itself and physically demand your attention. For example, typing stop(; when you mean stop(); will result in these two errors:
You're probably thinking these are the worst errors, as they physically crash the program. But hey - you've got error codes (1083 and 1084), a description of the error and you can double click on the error to give you a rough idea of where the problem occurs. You can then read off the error message (see future tutorials) and react accordingly.
Compiler errors occur when Flash either knows or thinks there will probably be in the case of warnings, a problem. Most of the time it knows there will be a problem: it hasn't found the other half of my parenthesis for example. It's done a quick check of the code and thought, 'Hey, that looks a bit funny'. These are set errors, which is why you get descriptions alongside them.
Runtime errors
Runtime errors are errors that occur when you run the program but aren't picked up before hand. They generally result from values changing outside of your control (oh why did he have to enter 03/12/2009 when all I wanted was 03/12/09 ?), which are then passed to functions. One example would be this line: gotoAndPlay("");. It passes the compiler error checker - "" is a valid string - but when it gets to the function it finds out that:ArgumentError: Error #2109: Frame label not found in scene Scene 1... .
On the upside, we still have an error number, a description and probably a line number too. You can also typeset you variables, if they're always going to be strings or whatever (var astring:String). That will force compiler errors. On the downside, the situation in which this occurs you may never meet (how could anyone be that stupid?), but your customers might. Still, they're better than the next category...
Logic Errors
1 + 2 = ?. Of course, you're expecting the answer 3. I, unfortunately for you at least, am not. Well, here goes... According to Flash, the answer is (of course) 12. Why? Because I coded them as strings before trying to add them together. In this small example, it's obvious where you've gone wrong, but it may not always be that way. For example, it might be a little harder to work out that there should actually be a plus sign in (Math.atan(_xdeg) - 1)*(Math.sin(1 - _ydeg)). To make a sweeping generilsation, I suppose that's what can annoy the programmer most - the unending logical nature of computers. At the end of the day you only ever have yourself to blame for not thinking it through before hand.
You may never know you have a logic error until your remote-controlled mission to Mars has crashed straight into it because you had +1 when you meant -1. If you do realise though, help is at hand. Firstly, typeset all your variables (see above). Next, throw in a lot of traces and see what happens and what doesn't. You can also step through the code using Flash's debug menu.
One last 'logic' tip: if your head hurts, draw a helpful diagram.
Next time we shall be looking at individual, common, errors. Catch you for that.
Harry.
