Command-line debugger

If you encounter errors in your applications, you can use the debugging tools to set and manage breakpoints in your code; control application execution by suspending, resuming, and terminating the application; step into and over the code statements; select critical variables to watch; evaluate watch expressions while the application is running, and so on.

About debugging

Debugging Adobe® Flex® applications can be as simple as enabling trace() statements or as complex as stepping into an application’s source files and running the code, one line at a time. The Adobe® Flash® Builder™ debugger and the command-line debugger, fdb, let you step through and debug the files used by your Flex applications.

To debug a Flex application, you must generate a debug SWF file. This is a SWF file with debug information in it. You then connect fdb to the debugger version of Adobe® Flash® Player that is running the debug SWF file.

The debugger is an agent that communicates with the application that is running in Flash Player. It connects to your application with a local socket connection. As a result, you might have to disable anti-virus software to use it if your anti-virus software prevents socket communication. The debugger uses this connection to transfer information from the SWF file to the command line so that you can add breakpoints, inspect variables, and do other common debugging tasks. The port through which the debugger connects to your application is 7935. You cannot change this port.

This topic describes how to use the fdb command-line debugger. To use the Flash Builder debugger, see Debugging Tools in Flash Builder.

To use either debugger, you must install and configure the debugger version of Flash Player. To determine if you are running the debugger version or the standard version of Flash Player, open any Flex application in the player and right-click the mouse button. If you see the Show Redraw Regions option, you are running the debugger version of Flash Player. For more information about the debugger version of Flash Player, and how to detect which player you are running, see Using the debugger version of Flash Player.

Using the command-line debugger

The fdb command-line debugger is located in the flex_install_dir/bin directory. To start fdb, open a command prompt, change to that directory, and enter fdb.

For a description of available commands, use the following command:

(fdb) help

For an overview of the fdb debugger, use the following command:

(fdb) tutorial

Generating debug SWF files

To debug a Flex application, you first generate a debug SWF file. Debug SWF files are similar to other application SWF files except that they contain debugging-specific information that the debugger and the debugger version of Flash Player use during debugging sessions. Debug SWF files are larger than non-debug SWF files, so generate them only when you are going to debug with them.

To generate the debug SWF file using the mxmlc command-line compiler, you set the debug option to true, either on the command line or in the flex-config.xml file. The following example sets the debug option to true on the command line:

mxmlc -debug=true myApp.mxml

Flash Builder generates debug SWF files by default in the project’s /bin-debug directory. To generate a non-debug SWF file in Flash Builder, you use the Export Release Build feature. This generates a non-debug SWF file in the project’s /bin-release directory. You can also manually set the debug compiler option to false in the Additional Compiler Arguments field of the project’s properties.

You can use fdb in any gdb-compatible debugging environment. For example, you can use M‑x gdb inside Emacs and specify fdb.exe as the gdb command.

Command-line debugger limitations

The command-line debugger supports debugging only at the ActionScript level and does not support the Flash timeline concept. The debugger also does not support adding breakpoints inside script snippets in MXML tags. You can set breakpoints on event handlers defined for MXML tags.

Flash Player may interact with a server. The debugger does not assist in debugging the server-side portion of the application, nor does it offer support for inspecting any of the IP transactions that take place from Flash Player to the server, and vice versa.

Command-line debugger shortcuts

You can open commands within the fdb debugger by using the fewest number of nonambiguous keystrokes. For example, to use the print command, you can type p, because no other command begins with that letter.

Using the default browser

When you debug an application in a web browser, fdb opens the player in the default browser. The default browser is the browser that opens when you open a web-specific file without specifying an application. You must also have the debugger version of Flash Player installed with this browser. If you do not have the debugger version of Flash Player, Flash displays an error indicating that your Flash Player does not support all fdb commands.

Your default browser might not be the first browser that you installed on your computer. For example, if you installed another web browser after installing Microsoft Internet Explorer, Internet Explorer might not be your default browser.

Determine your default browser

From the Windows toolbar, select Start.
Select Run and enter a URL in the Run dialog box. For example:
```
http://www.adobe.com
```
Click OK.

Windows opens the default browser or displays an error message indicating that there is no application configured to handle your request.

Set Internet Explorer 6.x as your default browser

Open the Internet Explorer application.
Select Tools > Internet Options.
Select the Programs tab.
Select the “Internet Explorer should check to see whether it is the default browser” option, and click OK.

The next time you start Internet Explorer, Internet Explorer prompts you to make it the default browser. If you are not prompted, Internet Explorer is already your default browser.

Set Firefox as your default browser

Open the Firefox application.
Select Tools > Options.
Select the General icon to view general settings.
Select the “Firefox should check to see if it is the default browser when starting” option, and click OK.

The next time you start FireFox, FireFox prompts you to make it the default browser. If you are not prompted, FireFox is already your default browser.

About the source files

Each application can have any number of ActionScript files. Some of the files that fdb steps into are external class files, and some are generated by the Flex compilers.

In general, Flex generates a single file that contains ActionScript statements used in <fx:Script> blocks in the root MXML file, and an additional file for each ActionScript class that the application uses. Flex generates many source files so that you can navigate the application from within the debugger.

To view a list of files that are used by the application you are debugging, use the info files command. For more information, see Getting status.

The generated ActionScript class files are sometimes referred to as compilation units. For more information about compilation units, see About incremental compilation.

Using RSLs when debugging

By default, you compile applications against the signed framework RSLs. The signed framework RSLs are optimized, which means that they do not include debugging information. Flash Builder automatically uses unoptimized debug RSLs when you launch the debugger. If you compile on the command line, however, and use the command line debugger, you must either disable RSLs or specify non-optimized RSLs to use. Otherwise, you will not be able to set break points or take advantage of other debugging functionality.

For more information, see Example of using the framework RSLs on the command line

Starting a debugging session

You start a debugging session by using the fdb command-line debugger. After you start a session, you typically type continue once before you set break points and perform other debugging tasks. This is because the first frame that suspends debugging occurs before the application has finished initialization.

For more information about which commands are available after you start a debugging session, see Using the command-line debugger commands.

Starting a session with the stand-alone Flash Player

You can start a debugging session with the stand-alone debugger version of Flash Player. You do this by compiling the application into a SWF file, and then invoking the SWF file with the fdb command-line debugger. The fdb debugger opens the debugger version of the stand-alone Flash Player.

The debugger version of the stand-alone Flash Player runs as an independent application. It does not run within a web browser or other shell. The debugger version of the stand-alone Flash Player does not support any server requests, such as web services and dynamic SWF loading, so not all applications can be properly debugged inside the debugger version of the stand-alone Flash Player.

Debug with the stand-alone Flash Player

Compile the Flex application’s debug SWF file and set the debug option to true.
The following example compiles an application with the mxmlc command-line compiler:
```
mxmlc -debug=true myApp.mxml
```
You can also compile an application SWF file by using the Flash Builder compiler. For more information on Flex compilers, see About the Flex compilers.
Find the flex_install_dir/bin directory. You installed the Flex application files to this directory.
Type fdb from the command line. The fdb prompt appears.
You can also open fdb with the JAR file, as the following example shows:
```
 java -jar ../lib/fdb.jar
```
Type run at the fdb prompt, followed by the path to the SWF file, as shown in the following example:

(fdb) run c:/myfiles/fonts/EmbedMyFont.swf

The fdb debugger starts the Flex application in the debugger version of the stand-alone Flash Player, and the (fdb) command prompt appears. You can also start a session by typing fdb filename.swf at the command prompt, rather than by using the run command.

Starting a session in a browser

You can start a debugging session in a browser. This requires that you pre-compile the SWF file and are able to request it from a web server.

Debug in a browser

Compile the Flex application’s debug SWF file and set the debug option to true. The following example compiles an application with the mxmlc command-line compiler:
```
mxmlc -debug=true myApp.mxml
```
You can also compile an application SWF file by using the Flash Builder compiler. For more information on Flex compilers, see About the Flex compilers.
Create an HTML wrapper that embeds this SWF file, if you have not already done so. For more information on creating a wrapper, see Creating a wrapper.
Copy the SWF file and its wrapper files to your web server.
Find the flex_install_dir/bin directory. You installed the Flex application files to this directory.
Type fdb in the command line. The fdb prompt appears.

You can also open fdb with the JAR file, as the following example shows:
```
java -jar ../lib/fdb.jar
```
Type run at the fdb prompt:
```
(fdb) run
```
This instructs fdb to wait for a player to connect to it.
In your browser, request a wrapper that embeds the debug SWF file. Do not request the SWF file directly in a browser because some browsers do not allow you to run a SWF file directly.

Alternatively, you can type run filename.html at the command line, and fdb launches the browser for you. The filename should include the entire URL; for example:
```
(fdb) run http://localhost:8100/flexapps/index.html
```

Configuring the command-line debugger

You can configure the current session of the fdb command-line debugger using variables that exist entirely within fdb; they are not part of your application. The configuration variables are prefixed with $.

The following table describes the most common configuration variables used by fdb:

Variable	Description
$invokegetters	Set to 0 to prevent fdb from firing getter functions. The default value is `1` (enabled).
$listsize	Sets the number of lines to display with the list command. The default value is `10`.

To set the value of a configuration variable, you use the set command, as the following example shows:

(fdb) set $invokegetters = 0

For more information on using the set command, see Changing data values.

Using the command-line debugger commands

The fdb command-line debugger includes commands that you use to debug and navigate your Flex application.

Running the debugger

The fdb debugger provides several commands for stepping through the debugged application’s files. The following table summarizes those commands:

Command	Description
`continue`	Continues running the application.
`file [`file`]`	Specifies an application to be debugged, without starting it. This command does not cause the application to start; use the `run` command without an argument to start debugging the application.
`finish`	Continues until the function exits.
`next [`N`]`	Continues to the next source line in the application. The optional argument `N` means do this `N` times or until the program stops for some other reason.
`quit`	Exits from the debug session.
run [file]	Starts a debugging session by running the specified file. To run the application that the file command previously specified, execute the `run` command without any options. The `run` command starts the application in a browser or stand-alone Flash Player.
`step [`N`]`	Steps into the application. The optional argument `N` means do this `N` times or until the program stops for some other reason. These commands are nonblocking, which means that when they return, the client has at least begun the operation, but it has not necessarily finished it.

When you start a session, fdb stops execution before Flex renders the application on the screen. Use the continue command to get to the application’s starting screen.

The following example shows a sample application after it starts:

(fdb) continue 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] RadioButtonGroup.addInstance: instance = _level0._VBox0._Accordion0._For 
m2._FormItem3._RadioButton1 data = undefined label = 2005 
[trace] RadioButtonGroup.addInstance: instance = _level0._VBox0._Accordion0._For 
m2._FormItem3._RadioButton2 data = undefined label = 2004 
[trace] RadioButtonGroup.addInstance: instance = _level0._VBox0._Accordion0._For 
m2._FormItem3._RadioButton3 data = undefined label = 2005 
[trace] RadioButtonGroup.addInstance: instance = _level0._VBox0._Accordion0._For 
m2._FormItem3._RadioButton4 data = undefined label = 2006 
[trace] ComboBase: y = 0 text_mc.bl = 12 
[trace] ComboBase: y = 0 text_mc.bl = 12 
[trace] ComboBase: y = 0 text_mc.bl = 12 
[trace] ComboBase: y = 0 text_mc.bl = 14

During the debugging session, you interact with the application in the debugger version of Flash Player. For example, if you select an item from the drop-down list, the debugger continues to output information to the command window:

[trace] SSL : ConfigureScrolling 
[trace] SSP : 5 51 true 47 
[trace] ComboBase: y = 0 text_mc.bl = 14 
[trace] layoutChildren : bRowHeightChanged 
[trace] >>SSL:layoutChildren 
[trace] deltaRows 5 
[trace] rowCount 5 
[trace] <<SSL:layoutChildren 
[trace] >>SSL:draw 
[trace] bScrollChanged 
[trace] SSL : ConfigureScrolling 
[trace] SSP : 5 51 false 46 
[trace] SSL Drawing Rows in UpdateControl 5 
[trace] <<SSL:draw

You can store commonly used commands in a source file, and then load that file by using the source command. For more information, see Accessing commands from a file.

Setting breakpoints

Setting breakpoints is a critical aspect of debugging any application. You can set breakpoints on any ActionScript code in your Flex application. You can set breakpoints on statements in any external ActionScript file, on ActionScript statements in an <fx:Script> tag, or on MXML tags that have event handler properties. In the following MXML code, click is an event handler property:

<s:Button click="ws.getWeather.send();"/>

Breakpoints are maintained from session to session. However, when you change the target file or quit fdb, breakpoints are lost.

The following table summarizes the commands for manipulating breakpoints with the ActionScript debugger:

Command	Description
`break [args]`	Sets a breakpoint at the specified line or function. The argument can be a line number or function name. With no arguments, the `break` command sets a breakpoint at the currently stopped line (not the currently listed line). If you specify a line number, fdb breaks at the start of code for that line. If you specify a function name, fdb breaks at the start of code for that function.
`clear [args]`	Clears a breakpoint at the specified line or function. The argument can be a line number or function name. If you specify a line number, fdb clears a breakpoint in that line. If you specify a function name, fdb clears a breakpoint at the beginning of that function. With no argument, fdb clears a breakpoint in the line that the selected frame is executing in. Compare the `delete` command, which clears breakpoints by number.
commands [breakpoint]	Sets commands to execute when the specified breakpoint is encountered. If you do not specify a breakpoint, the commands are applied to the last breakpoint.
condition bp_num [expression]	Specifies a condition that must be met to stop at the given breakpoint (identified by the breakpoint number). The fdb debugger evaluates expression when the breakpoint is reached. If the value is `true` or nonzero, fdb stops at the breakpoint. Otherwise, fdb ignores the breakpoint and continues execution. To remove the condition from the breakpoint, do not specify an expression. You can use conditional breakpoints to stop on all events of a particular type. For example, to stop on every `initialize` event, use the following commands: (fdb) break UIEvent:dispatch Breakpoint 18 at 0x16cb3: file UIEventDispatcher.as, line 190(fdb) condition 18 (eventObj.type == 'initialize')
`delete [args]`	Deletes breakpoints. Specify one or more comma- or space-separated breakpoint numbers to delete those breakpoints. To delete all breakpoints, do not provide an argument.
disable breakpoints [bp_num]	Disables breakpoints. Specify one or more space-separated numbers as options to disable only those breakpoints.
enable breakpoints [bp_num]	Enables breakpoints that were previously disabled. Specify one or more space-separated numbers as options to enable only those breakpoints.

The following example sets a breakpoint on the myFunc() method, which is triggered when the user clicks a button:

(fdb) break myFunc 
Breakpoint 1 at 0x401ef: file file1.mxml, line 5 
(fdb) continue 
Breakpoint 1, myFunc() at file1.mxml:5 
    5ta1.text = "Clicked"; 
(fdb)

To see all breakpoints and their numbers, use the info breakpoints command. This will also tell you if a breakpoint is unresolved.

You can use the commands command to periodically print out values of objects and variables whenever fdb encounters a particular breakpoint. The following example prints out the value of ta1.text (referred to as $1), executes the where command, and then continues when it encounters the button’s click handler breakpoint:

(fdb) commands 1 
Type commands for when breakpoint 1 is hit, one per line. 
End with a line saying just 'end'. 
>print ta1.text 
>where 
>continue 
>end 
(fdb) cont 
Breakpoint 1, myFunc() at file1.mxml:5 
    5ta1.text = "Clicked"; 
$1 = "" 
#0 [MovieClip 1].myFunc(event=undefined) at file1.mxml:5 
#1 [MovieClip 1].handler(event=[Object 18127]) at file1.mxml:15

Breakpoints are not specific to a single SWF file. If you set a breakpoint in a file that is common to multiple SWF files, fdb applies the breakpoint to all SWF files.

For example, suppose you have four SWF files loaded and each of those SWF files contains the same version of an ActionScript file, view.as. To set a breakpoint in the init() function of the view.as file, you need to set only a single breakpoint in one of the view.as files. When fdb encounters any of the init() functions, it triggers the break.

By using the watch command, you can set watchpoints on variables. When that variable changes, the debugger halts. Watched variables can be any member variable, but cannot be dynamic, getters, or local variables. The watch command has the following syntax:

(fdb) watch variable_name

Accessing commands from a file

You can use the source command to read fdb commands from a file and execute them. This lets you write commands such as breakpoints once and use them repeatedly when debugging the same application in different sessions or across different applications.

The source command has the following syntax:

(fdb) source file

The value of file can be a filename for a file in the current working directory or an absolute path to a remote file. To determine the current working directory, use the pwd command.

The following examples read in the mycommands.txt file from different locations:

(fdb) source mycommands.txt 
(fdb) source mydir\mycommands.txt 
(fdb) source c:\mydir\mycommands.txt

Examining data values

The print command displays values of members such as variables, objects, and properties. This command excludes functions, static variables, constants, and inaccessible member variables (such as the members of an Array).

The print command uses the following syntax:

print [variable_name | object_name[.] | property]

The print command prints the value of the specified variable, object, or property. You can specify the name or name.property to narrow the results. If fdb can determine the type of the entity, fdb displays the type.

If you specify the print command on an object, fdb displays a numeric identifier for the object.

To list all the properties of an object, use trailing dot-notation syntax. The following example prints all the properties of the object myButton:

(fdb) print myButton.

To print the value of a single variable, use dot-notation syntax, as the following example shows:

(fdb) print myButton.label

Use the what command to view the context of a variable. The what command has the following syntax:

(fdb) what variable

Use the display command to add an expression to the autodisplay list. Every time debugging stops, fdb prints the list of expressions in the autodisplay list. The display command has the following syntax:

(fdb) display [expression]

The expression is the same as the arguments for the print command, as the following example shows:

(fdb) display myButton.color

To view all expressions on the autodisplay list, use the infodisplay command.

To remove an expression from the autodisplay list, use the undisplay command. The undisplay command has the following syntax:

(fdb) undisplay [list_num]

Use the undisplay command without an argument to remove all entries on the autodisplay list. Specify one or more list_num options separated by spaces to remove numbered entries from the autodisplay list.

You can temporarily disable autodisplay expressions by using the disabledisplay command. The disable display command has the following syntax:

(fdb) disable display [display_num]

Specify one or more space-separated numbers as options to disable only those entries in the autodisplay list.

To re-enable the display list, use the enabledisplay command, which has the same syntax as the disable display command.

Changing data values

You can use the set command to assign the value of a variable or a configuration variable. The set command has the following syntax:

set [expression]

Depending on the variable type, you use different syntax for the expression. The following example sets the variable i to the number 3:

(fdb) set i = 3

The following example sets the variable employee.name to the string Reiner:

(fdb) set employee.name = "Reiner"

The following example sets the convenience variable $myVar to the number 20:

(fdb) set $myVar = 20

You use the set command to set the values of fdb configuration variables. For more information, see Configuring the command-line debugger.

Viewing file contents

You use the list command to view lines of code in the ActionScript files. The list command uses the following syntax:

list [- | line_num[,line_num] | [file_name:]line_num | file_name[:line_num] | [file_name:]function_name]

You use the list command to print the lines around the specified function or line of the current file. If you do not specify an argument, list prints 10 lines after or around the previous listing. If you specify a filename, but not a line number, list assumes line 1.

If you specify a single numeric argument, the list command lists 10 lines around that line. If you specify more than one comma-separated numeric argument, the list command displays lines between and including those line numbers.

To set the list location to where the execution is currently stopped, use the home command.

The following example lists code from line 10 to line 15:

(fdb) list 10, 15

If you specify a hyphen (-) in the previous example, the list command displays the 10 lines before a previous 10-line listing.

Specify a line number to list the lines around that line in the current file, as in the following example:

(fdb) list 10

Specify a filename followed by a line number to list the lines around that line in that file, as in the following example:

(fdb) list effects.mxml:10

Specify a function name to list the lines around the beginning of that function, as in the following example:

(fdb) list myFunction

Specify a filename followed by a function name to list the lines around the beginning of that function. This lets you distinguish among like-named static functions, as follows:

(fdb) list effects.mxml:myFunction

You can resolve ambiguous matches by extending the value of the function name or filename, as the following examples show:

Filenames:

(fdb) list UIOb 
Ambiguous matching file names: 
UIComponent.as#66 
UIComponentDescriptor.as#67 
UIComponentExtensions.as#68 
(fdb) list UIComponent.

Function names:

(fdb) list init 
Ambiguous matching function names: 
init 
initFromClipParameters 
(fdb) list init(

Viewing and changing the current file

The list command acts on the current file by default. To change to a different file, use the cf command. The cf command has the following syntax:

(fdb) cf [file_name|file_number]

For example, to change the file to MyApp.mxml, use the following command:

(fdb) cf MyApp.mxml

If you do not specify a filename, the cf command lists the name and file number of the current file.

To view a list of all files used by the current application, use the infofiles command. For more information, see Getting status.

Viewing the current working directory

Use the pwd command to view the file system’s current working directory, as the following example shows. This is the directory from which fdb was run.

(fdb) pwd 
c:/Flex2SDK/bin/

Locating source files

Usually, fdb can find the source files for your application to display them with the list command. In some situations, however, you need to add a directory to the search path so that fdb can find the source files. This can be necessary, for example, when the application was compiled on a different computer than you are using to debug the application.

You use the directory command to add a directory to the search path. This command adds the specified directory or directories to the beginning of the list of directories that fdb searches for source files. The syntax for the directory command is as follows:

(fdb) directory path

For example:

(fdb) directory C:\MySource;C:\MyOtherSource

On Windows, use the semicolon character as a separator. On Macintosh and UNIX, use the colon character as a separator.

To see the current list of directories in the search path, use the show directories command.

Using truncated file and function names

The fdb debugger supports truncated file and function names. You can specify file_name and function_name arguments with partial names, as long as the names are unambiguous.

If you use truncated file and function names, fdb tries to map the argument to an unambiguous function name first, and then a filename. For example, listfoo first tries to find a function unambiguously starting with foo in the current file. If this fails, it tries to find a file unambiguously starting with foo.

Printing stack traces

Use the bt command to display a back trace of all stack frames. The bt command has the following syntax:

(fdb) bt

Getting status

Use the info command to get general information about the application. The info command has the following syntax:

info [options] [args]

The info command displays general information about the application being debugged. The following table describes the options of the info command:

Option	Description
`arguments`	Displays the argument variables of the current stack frame.
`breakpoints`	Displays the status of user-settable breakpoints.
`display`	Displays the list of autodisplay expressions.
`files [arg]`	Displays the names of all files used by the target application. This includes authored files and system files, plus generated files. Also indicates the file number for each file. You can use wildcards and literals to select and sort the output. The `infofiles` command supports the following: `info files character` Alphabetically lists files with names that start with the specified character. The following example lists all files starting with the letter V: info files V `info files .extension` Alphabetically lists all files with the given extension. The following example lists all files with the as extension: info files .as `info files string` Alphabetically lists all files with names that include string.
`functions [arg]`	Displays all function names used in this application. The `info functions` command optionally takes an argument; for example: `infofunctions` Lists all functions in all files. `infofunctions` Lists all functions in the current file. `infofunctions MyApp.mxml` Lists all functions in the MyApp.mxml file.
handle	Displays settings for fault handling in the debugger.
`locals`	Displays the local variables of the current stack frame.
`sources`	Displays authored source files used by the target application.
stack	Displays the backtrace of the stack.
swfs	Displays all current SWF files.
targets	Displays the HTTP or file URL of the target application.
`variables`	Displays all global and static variable names.

For additional information about these options, use the help command, as the following example shows:

(fdb) help info targets

Handling faults and catching exceptions

Use the handle command to specify how fdb reacts to Flash Player exceptions during execution. To view the current settings, use the info command, as the following example shows:

(fdb) info handle

The handle command has the following syntax:

(fdb) handle exception [action]

The fault_type is the category of fault that fdb handles. The action is what fdb does in response to that fault. The possible actions are print, noprint, stop, and nostop. The following table describes these actions:

Action	Description
print	Prints a message if this type of fault occurs.
noprint	Does not print a message if this type of fault occurs.
stop	Stops execution of the debugger if this type of fault occurs.
nostop	Does not stop execution of the debugger if this type of fault occurs.

You can also use the catch command to halt the debugger when an exception of a specified type is encountered. The debugger halts even if there is a catch statement that catches the exception. The syntax of the catch command is as follows:

(fdb) catch exception_type

The exception_type argument is the type of exception that stops the debugger. For example, TypeError:

(fdb) catch TypeError

To halt the debugger on any exception, you can use a wildcard (“*”), as the following example shows:

(fdb) catch *

Getting help

Use the help command to get information on particular topics. The help command has the following syntax:

help [topic]

The help command provides a relatively terse description of each command and its usage. The following example opens the help command:

(fdb) help

Type help followed by the command name to get the full help information, as the following example shows:

(fdb) help delete

Terminating the session

You use the kill and exit commands to end the current debugging session and exit from the fdb application. The kill and exit commands do not take any arguments. If fdb opened the default browser, you can also terminate the fdb session by closing the browser window.

To stop the current session, use the kill command, as the following example shows:

(fdb) kill

Using the kill command does not quit the fdb application. You can immediately start another session. To exit from fdb, use the exit command, as follows:

(fdb) exit