Warning: Declaration of thesis_comment::start_lvl(&$output, $depth, $args) should be compatible with Walker::start_lvl(&$output, $depth = 0, $args = Array) in /nfs/c03/h08/mnt/50298/domains/gamedev.michaeljameswilliams.com/html/wp-content/themes/thesis_18/lib/classes/comments.php on line 0

Warning: Declaration of thesis_comment::end_lvl(&$output, $depth, $args) should be compatible with Walker::end_lvl(&$output, $depth = 0, $args = Array) in /nfs/c03/h08/mnt/50298/domains/gamedev.michaeljameswilliams.com/html/wp-content/themes/thesis_18/lib/classes/comments.php on line 0

Warning: Declaration of thesis_comment::start_el(&$output, $comment, $depth, $args) should be compatible with Walker::start_el(&$output, $object, $depth = 0, $args = Array, $current_object_id = 0) in /nfs/c03/h08/mnt/50298/domains/gamedev.michaeljameswilliams.com/html/wp-content/themes/thesis_18/lib/classes/comments.php on line 0

Warning: Declaration of thesis_comment::end_el(&$output, $comment, $depth, $args) should be compatible with Walker::end_el(&$output, $object, $depth = 0, $args = Array) in /nfs/c03/h08/mnt/50298/domains/gamedev.michaeljameswilliams.com/html/wp-content/themes/thesis_18/lib/classes/comments.php on line 0
How to Fix Bugs By Learning From the Experts — Michael James Williams

How to Fix Bugs By Learning From the Experts

by Michael James Williams on May 10, 2009 · 4 comments

in Articles

In the first part of this series, we looked at techniques for debugging you could do alone and offline (and there were some fantastic tips posted in the comments, so check them out if you missed them).

This time, we’ll look at how you can **benefit from the existing knowledge of experts** to save you hours of time trying to find out just why the heck the blasted enemy doesn’t explode even when you hit it like a million times.

###The Three Stages of Code Correction

When there’s a problem with your code, sometimes Flash will generate a warning message before it even creates the SWF. Sometimes Flash will throw an error upon reaching a certain point. Sometimes Flash won’t notice anything’s wrong, because it’s just software, able to think only in cold steely logic, and unable to understand any concepts you don’t explain to it very slowly.

Whichever of these is the case, there are three stages all programmers go through when learning to correct their code:

1. Defining the problem, in abstract terms
2. Learning how other experts solved the same type of problem, and applying these solutions
3. Figuring out their common personal causes for the problem, to speed up the process next time

Legends speak of a mythical *fourth* stage, in which the programmer learns not to make the mistake at all next time, but no developer in recorded history has ever reached this level.

Each stage takes longer than the previous. Let’s look at them in turn.

###Define the Problem

If you’ve got a warning or error code (they’ll appear in the Errors or Output panel), this stage is easy. After all, the point of these codes is to give a standard reference to a problem that everyone can share. Suppose you’re getting this code:

TypeError: Error #1009: Cannot access a property or method of a null object reference.

You actually have three pieces of information there:

– The **kind** of error: TypeError
– The **error code**: #1009
– The **error message**: Cannot access a property or method of a null object reference.

It’s an abstract set of data that in no way references your code (though as onedayitwillmake pointed out in the previous post’s comments, you can get the line of code that triggers this error if you use debug mode), but it’s a good place to start.

Sometimes you might just get a code, rather than a message. In this case, you should check out the AS3 LiveDocs. These make up the official documentation for ActionScript 3.0, and are written by Adobe experts. They’re also included with Flash — just hit the *Help* menu.

Three particularly useful pages are:

Runtime Errors
Compiler Warnings
Compiler Errors

Each of these give a list of the codes, their meanings and sometimes a description. Be careful, though — the same code number can mean different things in different contexts. For example, a compiler warning #1009 means %s '%s' has no type declaration, not Cannot access a property or method of a null object reference.

You can also find out more about the kind of error by looking up that error class’s page. For example, click here to check out the documentation on TypeError. In this example it’s of almost no use, as it doesn’t even mention “null object references”, but sometimes doing this will give you an extra hint as to what’s going on.

What if your problem is of the kind that Flash doesn’t recognise, so you don’t get an error or warning code at all? The LiveDocs can still be useful. Assuming you’ve narrowed down the problem, you should have a finite number of functions and classes involved that might be causing it. If you look each of them up, you may discover which of them is the troublemaker — perhaps one doesn’t work exactly the way you’d expect.

When looking stuff up in the LiveDocs, you can use the search inside Flash or on the LiveDocs website. I prefer to use these Firefox search plugins because they let me use the power of Google. The only problem is that I often find myself looking at the documentation for Flash Lite or AS2 instead of what I want (this can usually be solved by sticking ‘AS3′ in front of whatever it is I’m searching for).

###Other Developers’ Solutions

Now, I don’t mean asking other people for help via forums or email — we’ll cover that topic later. Here I’m talking about solutions other people came up with for similar problems to the ones you’re having, before you were even having them.

Not surprisingly, Google is a huge help in this situation. Try Googling ‘AS3 error 1009‘ and you’ll find dozens of people explaining what was causing this error for them and how they eventually solved it. Often you’ll find that one of these causes matches your situation, and you’ll be able to apply their solution immediately.

I just want to pause for a minute and make something clear.

Searching the Internet is a skill. Did you know you can use “speech marks” to group words together, so that Google will search for a phrase rather than individual words? Or that the && and || operators can be used in search queries, just as they can in *if* statements? If not, it’s worth reading up on that. Developing your searching skill is very important, not just when programming, but when doing any research at all. Don’t take it for granted.

OK, so besides Google, the other most useful resource is **blogs**. Are you RSS-subscribed to any Flash blogs? If not, you should be. I have an explanation of RSS at this page; the basic idea is that it’s an easy way to keep notified of whenever the author writes new content.

It might not seem very useful for debugging to be keeping up with the latest posts. After all, what are the chances of any of the info written today solving the problem you’re having right now? But that’s not the point.

Sometimes, other bloggers will have problems with their code. And sometimes, they will write about how to solve those problems. And if you are aware of — not necessarily *reading*, but aware of — everything they write, you’ll know this. Then, later on, when you have that same problem, you can think, “hey, this is the problem that Bill Blogger was having a while ago!” All you need to do at that point is check out Bill Blogger’s website and you’ll be set.

There’s a really simple system you can use that’ll make this even easier. If you have a browser that supports *tagged browsing* you can start straight away; otherwise you’ll need to either switch browsers or sign up to a free service like Delicious.

Whenever you see a post that makes you think, “hm, this could be useful later,” bookmark it and tag it with every keyword you can think of to make it easier to remember later. For example, you could tag this post with ‘as3, flash, programming, code, debugging, bugs, errors, warnings, blogs, livedocs’. Later on, if you have an AS3 error and you want to know how to debug it, you can look through all your bookmarks tagged ‘as3, bugs’ and this one will come up.

I use a couple other tags for certain situations:

– The best articles on a certain topic get a **bestofx** tag, so I can find them more easily later.
– Articles written by an author that I’m already familiar with get tagged with the author’s (screen)name, so that I can look up “that great series by Grant Skinner on garbage collection“.

If you want some decent blogs to add to (or start) your collection, check out my Links page. I actually follow more blogs than are listed there, but many of them are grouped together in FlashGameBlogs.com. My own RSS feed is at this link.

###Learn From Your Mistakes

There’s a number of reasons why a TypeError #1009 might get thrown. It could be because the developer set a variable to null, and then forget about it and tried to use it again:

var hero:MovieClip = new HeroMC();
//some code
removeChild( hero );
hero = null;
//more code
hero.x = hero.x + 10;
//oops! error will be thrown here

It could be because the object in question got garbage collected without the programmer realising.

But when I see it, 99% of the time it’s because I’ve forgotten to type = new Whatever(); like so:

var hero:MovieClip;
//some code
hero.x = hero.x + 10;
//oops! error will be thrown here

I am **not** saying that this is The Most Common Cause of Error #1009. I am saying that this is **my** most common cause of error #1009. I’ve learned that despite having made this mistake hundreds of times, I *still* make it, and more often than anything else that could cause a #1009. Other people hardly ever make this mistake, but often forget when they’ve set a variable to null.

Being predictable in my mistakes is irritating but very useful. Whenever an error #1009 is thrown, I know immediately that I should look for a var without a new. I’m flawed, but I can live with that.

If, after all this research, you still can’t solve your problem, then it’s time to ask for help. The next post in this series is all about that; click here to read it.

What common mistakes do you still make all the time? Know any great Flash dev blogs that I’m missing out on?

{ 4 comments… read them below or add one }

MichaelJWilliams May 10, 2009 at 6:32 pm

@rosedragoness pointed me towards Shine Draw, a site all about comparing Flash to Silverlight. Looks interesting!

Also, GamingYourWay’s latest post is a perfect example of what I’m talking about.

flashm May 11, 2009 at 10:38 pm

another great post, for all that i use this thing from a while

Michael Williams May 19, 2009 at 12:08 am

Thanks, flashm.

Another great new tool is HexoSearch. This is a search engine designed to search for ActionScript. So far it seems pretty useful 🙂

Michael Williams June 25, 2009 at 6:28 pm

And I just came across http://www.actionscripterrors.com/

It’s in beta, but it looks like it could be useful.

Leave a Comment

Writing code? Write <pre> at the start and </pre> at the end to keep it looking neat.

Previous post:

Next post: