Foundation Game Design with ActionScript 3.0, Second Edition (10 page)

But Flash Builder doesn't just leave you with vague error messages; it points to where in your code it thinks the problem is. If you look at the left side of your editor window, you'll see a small red circle with an X through it. Flash Builder thinks the problem lies in that line of code.
Figure 1-35
shows an example.

Figure 1-35.
Flash Builder will point to the line of code with the possible error.

The line that Flash Builder highlights is an important clue! However, it can be very misleading because Flash Builder only tells you the point at which it stopped being able to understand your code. Usually the real the problem is at a point which is
just before this spot
.

This can be confusing! Here's a more concrete example: imagine you're walking through the woods, trip on the root of a tree, and bump your head on a rock. Flash Builder will point to the rock as the problem. But you know that the real problem is the root of the tree.

Take a good look at
Figure 1-35
and compare it with the final code you wrote in the previous section. Does it look like there's anything wrong with the line that Flash Builder is pointing to? No, it's perfectly fine.

But take a look at the line just before it. This is what it looks like:

Do you notice something wrong? Yes! The closing parenthesis is missing. The line should look like this:

These kinds of simple mistakes are very easy to make, especially when you're just learning how to program and all of this is completely unfamiliar to you.

But Flash Builder didn't tell you that this was the problem. It pointed you to the rock that it bumped its head on, not the tree root that tripped it up. But it did give you an idea of where to look. If you fixed this code and debugged the program again, it would run perfectly and all the error messages would disappear.

Unfortunately, the compiler doesn't know what you intend your code to do; it can only tell you what it expects and what it doesn't understand. If you're lucky, it precisely pinpoints the problem. But more often than not, it will just be able to give you a general idea of where to look and what to look for. It's a bit like a two-year-old yelping with pain and pointing to his big toe. You know where the problem is, but whether it's a thumbtack, a bee sting, or just another way of saying, “The last time I did this you gave me some chocolate,” the remedy will depend on experience, skeptical investigation, and a thoughtful diagnosis. It's up to you to intelligently analyze what you think the error is telling you and what you might have to fix or change to get your program running properly.

If you're not sure where the problem with your program lies, ask yourself whether one or more of these might be the issue:

• Did you spell everything correctly and use the correct case?
  
• Did you save the files in the correct location, and do the spelling and case of your folders and files match the package and class names? (This generally isn't a problem if you're using Flash Builder, which does these things for you automatically, but it could be with another IDE.)
  
• Are all the AS3.0 keywords (such as
  import
,
  package
, and
  function
) a blue or purple color? If one of them isn't, that's a clear indication that you might have spelled or capitalized it incorrectly.
  
• Have you closed all your curly braces and parentheses?
  
• Did your cat jump on the keyboard while you were in the kitchen getting another cup of coffee?
  

And here are some more general pointers that you should always keep in mind while debugging your programs:

• If you receive more than one error message, always fix the first one first. Subsequent errors are usually the result of bits of code that depend on the earlier bits of code working correctly. Fix the first one, and the correction will cascade through the code and often magically correct the rest.
  
• Check the line of code that's
  just above the line that Flash thinks is the problem.
  Often, small mistakes in the line above, which might not be big enough in themselves to generate a compile error, could be enough to trip up the code in the next line down.
  
• Always save the AS file
  you're working on before you compile it again!
  I can't stress enough how common an oversight this is. A programmer will find an error and fix it, but then gets exactly the same error message when the SWF is republished. This is because the file wasn't saved after the fix was made, so the earlier saved version of the file is the one that Flash is actually compiling. This is not a problem if you're using Flash Builder, because it will automatically save the AS file for you before it attempts to run your code, but most other IDEs won't do this.
  
• Make only one single change before you compile the program to test it again. If your program worked and then suddenly stopped working after you made that change, you know exactly what is causing the problem. If you run and debug it only after making five changes and it doesn't work, you won't know which of those five things is tripping you up.
  
• Finally, the programmer's universal mantra: test early, test often. Do lots of testing and solve lots of tiny manageable problems early on to avoid having to deal with hulking intractable problems that can grind your project to a halt later.
  

Except for a few exceptional cases, this is the last discussion of debugging issues in any detail in this book. You'll be on your own from here on out, but the sooner you gain practice debugging your own code, the better. Experience counts for everything in this realm, and there is no better whetstone upon which to sharpen your skills as a programmer than a tricky debugging problem.

Also, get used to the Problems window—you'll be seeing a lot of it! It will become your closest ally in finding and tracking down problems.

This section lists some common error messages that you might see in your first attempts at debugging, with suggestions as to what the problem could be.

• 1087: Syntax error: extra characters found after end of program.
You probably forgot to open or close one of the curly braces.
  
• 1116: A user-defined namespace attribute can only be used at the top level of a class definition.
You misspelled a keyword in the class definition. Maybe you spelled “public” as “pulbic.”
  
• 1071: Syntax error: expected a definition keyword (such as function) after attribute public, not clas.
You spelled the word “class” as “clas.” This error will often be displayed when you misspell a keyword.
  
• 1084: Syntax error: expecting leftbrace before exteds
.
  You misspelled the word “extends.”
  
• 1017: The definition of base class Sprie was not found.
You misspelled the word “Sprite.”
  
• 1017: The definition of base class Sprite was not found.
You misspelled one of the words, such as “flash” or “display” in this line of code:
  import flash.display.Sprite;
You might also have left out one of the dots between the words.
  
• 1114: The public attribute can only be used inside a package.
You probably misspelled the word “package.”
  
• 1153: A constructor can only be declared public.
You misspelled the word “public” in the constructor method.
  
• 1071: Syntax error: expected a definition keyword (such as function) after attribute public, not functon.
You misspelled the word “function.”
  
• A file found in a source-path ‘HelloWorld– must have the same name as the class definition
inside the file ‘HeloWorld’.
You misspelled “HelloWorld” as “HeloWorld” in the class definition.
  
• 1008: return value for function ‘HeloWorld’ has no type declaration.
You misspelled “HelloWorld” as “HeloWorld” in the constructor method.
  
• 1084: Syntax error: expecting identifier before leftbrace.
You forgot to close a parenthesis.
  
• 1180: Call to a possibly undefined method trae.
You misspelled “trace” as “trae.”
  
• 1084: Syntax error: expecting rightparen before semicolon.
You forgot to close a parenthesis.
  

Don't let these error messages scare you! You'll soon get a feeling for what they're trying to tell you, and by carefully checking your code you'll always be able to find the source of the problem.

If you're unsure about any of the code in this book, you can download the original source files that I wrote and check your work against mine. You can download them from the book's download page at
www.apress.com
. Open the folder for the chapter you are working on, and you'll find the folders and files organized exactly as I've described them in this book. You can open any of the individual files directly in Flash Builder or open the whole folder as a Flash Builder project.

To open the source files as a project, select File
Import Flash Builder project from the main menu. A new dialogue box will open, asking whether you want to import a file or a project folder. Select project folder and click Finish. The project will be imported into Flash Builder, and you can then run and debug it, just as you can run and debug your own programs.

If the project folder you're trying to import has the same name as a project currently open in Flash Builder, rename the project folder before you import it.

Flash Builder is a complex bit of software that contains many more features than you'll probably ever need. Let's take quick look at some of the most useful.

The ActionScript editing window has a few advanced features which, unfortunately for beginners, can result in some frustrating quirks if you're not aware of them. They could cause your work to seem to disappear or not run properly. However, with a bit more experience, you'll actually find these features extremely helpful.

First, the Editing window allows you to
collapse
your code. Look at the very left side of the window and you'll see small minus signs. There's a minus sign next to each block of code. If you click one of those minus signs, the block of code collapses into a single line. It looks like your code has disappeared completely, but it hasn't. Click the new plus sign next to the code block, and your code appears again. This is useful if you're working on a very long program and want to temporarily hide bits of code so that they don't distract you from other bits you're working on.
Figure 1-36
illustrates this.