To start you out on the right track, let's first start with the basics of debugging. You'll learn all about breakpoints, how to use them in your ActionScript 3.0 code, and the role they play in debugging your Flash application.
Whenever you use a debugger, it is very important to be able to run through the script line by line in order to isolate the area of the code that is causing an error or a function that is returning an unexpected value. Rather than simply playing the script from beginning to end (as it would run in Flash Player), it is very helpful to add breakpoints to specific lines of code in your script. Breakpoints allow you to define a point at runtime where the SWF will pause when viewed in the debugger.
The ability to pause the code at a specified line makes it possible to investigate the progress of the script, so that you can closely examine what is happening—both visually and by researching the values assigned to variables (more about that later). Breakpoints work the same way in an ActionScript class and the ActionScript editor for frame scripts in the timeline of an FLA file.
Setting up breakpoints is easy. To add a breakpoint, simply click in the left margin of the line of you want to put a breakpoint. The breakpoint is displayed as a red dot next to the code (see Figure 1).

Figure 1. Adding a breakpoint by clicking once in the column to the left of the line numbers
To remove a single breakpoint, click the red dot to remove the breakpoint. To remove all breakpoints at once, select Debug > Remove All Breakpoints from the top menu.
Breakpoints are persistent. When you save a FLA file or an ActionScript class with breakpoints defined, they appear again the next time you open the file.
To run your code through the debugger, simply select Debug > Debug Movie from the top menu. If you attempt to debug a FLA file that does not contain any code, a warning message will appear: "You cannot debug this SWF because it does not contain ActionScript" (see Figure 2).

Figure 2. Error when attempting to run a movie through the ActionScript 3.0 debugger that does not contain code
There are two ways to include code in your Flash project. You can either write code as frame scripts on a timeline of the FLA or you can reference an external ActionScript class from the FLA file.
First, let's examine a simple FLA file that contains a dynamic text field with an instance name artists_txt. For this example, imagine that the following snippet of ActionScript exists on Frame 1 of the main Timeline:
var artists:Array = ["John Lennon","Paul McCartney","George Harrison","Ringo Starr"];
var current_artist:String = "";
for(var i:uint=0; i<artists.length; i++) {
current_artist = artists[i];
artist_txt.text = current_artist;
}
This example is designed to show how useful it is to use breakpoints and evaluate the values assigned to variables when a FLA is run through the ActionScript 3.0 debugger. In the code snippet above, an array containing the names of the four members of the Beatles is defined. A variable named current_artist is declared and then a for loop is used to assign the value associated with the current index of the array. This text is displayed in the dynamic text field.
If you were to run this movie in Flash Player by selecting Control > Test Movie, the movie would play and the dynamic text field would display Ringo Starr.
Go back to the FLA and add a breakpoint next to line 6. This is the line of code where the artist_txt text field is assigned a value. By setting a breakpoint on line 6, you can pause the script at that specific point to see what happens. If you run the debugger now (Debug > Debug Movie) you'll see the FLA file compile to a SWF. The movie launches in a window running the debug version of Flash Player and the interface changes to reveal the debugging interface (see Figure 3).

Figure 3. ActionScript 3.0 debugger interface
You may set as many breakpoints as you'd like, so that you can evaluate each line of code in the movie as desired. The interface provides valuable feedback about the variables, and the values it returns help you troubleshoot issues within the code. If Flash Player were used to run the movie, the code would execute so quickly that it would be difficult to tell exactly where the code was misbehaving.
It's time now to add breakpoints to an ActionScript class. The example below is a simple StringUtils class that includes a method to reverse a given string:
package {
public class StringUtils {
public function StringUtils() {}
public static function reverse(s:String):String {
var tmp_array:Array = s.split("");
tmp_array.reverse();
var tmp_string:String = tmp_array.join("");
return tmp_string;
}
}
}
To evaluate what the code is doing, add a breakpoint on line 11. This is the section of the script where the tmp_string variable is returned by the reverse method of the class (see Figure 4).

Figure 4. Adding a breakpoint to the line of code that returns the value of a variable in order to ensure the value is correct
Now that you've added the breakpoint, create a new FLA file that uses the StringUtils class. This is necessary because the FLA file is the movie that runs through the debugger. On Frame 1 of the main Timeline, add the following line of code:
StringUtils.reverse("Flash CS3 makes debugging fun!");If you run this Flash project using the regular Flash Player (Control > Test Movie), you won't see anything. This is because the return value from reverse method of the StringUtils class was not coded to display or do anything. However, if you run the FLA file through the debugger (Debug > Debug Movie), you'll see the debugger interface reveal a great deal of information that describes what is happening in the compiled SWF behind the scenes (see Figure 5).

Figure 5. Feedback from the debugger regarding the information Flash Player accesses as the movie runs