# Debugging Your Application

You can use the WebLogic Workshop integrated debugger to debug your application. The debugger allows you to set breakpoints, step through your code line-by-line, view local variables, set watches on variables, and view the call stack and exception information.

There are a variety of properties that can be set for the debugger. Some are set on a project basis, while others apply only to Java and Control Projects.

You can use the debugger on runnable files, non-runnable files, non-Workshop enabled servers, and projects developed against a remote server. You can also attach to JUnit and use the JUnit functionality in conjunction with the Weblogic WorkShop Debugger.

## Using the Debugger

In order to debug an application, you must have a way to exercise the application as a real client would. WebLogic Workshop includes a Test Browser in which you may test Workshop web applications and web services. When you run a web application or web service, the Test Browser automatically loads Test View, a tool for exercising the application.

To start the debugger, click the Start button on the toolbar or press Ctrl-F5. To pause debugging, click the Pause button on the toolbar. To stop debugging, click the Stop button on the toolbar.

When the debugger is started, the WebLogic Workshop Debugger command window is opened for the debugger proxy. This window must remain open in order to use the debugger. If you close this window, your breakpoints will not be hit when you test your application.

While your application is running in the debugger, it is unavailable to clients other than the Test Browser.

To debug your project, you will use breakpoints, the commands that allow you to navigate the code, and the debug windows, which show information about variable values, how the program is running, and what code is executed.

## Breakpoints

Breakpoints allow you to halt execution at a specified point in the program so you can observe information about its operation. When you halt execution at a breakpoint, you can step through the program line-by-line, step over a breakpoint, and use the debug windows to change values or execute arbitrary code.

The types of breakpoints you can set include:

- Line Breakpoints - halts execution at the line of code before the breakpoint
- Exception Breakpoints - halts execution when an exception occurs
- Method Breakpoints - halts execution as soon as a specified method is called
- Taglib Breakpoints - halts at the taglib method being implemented
- JSP Breakpoints - used with JSP files only

To create Exception and Method breakpoints, select Debug-->Create Breakpoint and enter the appropriate settings in the Create Breakpoint dialog.

To create a Line breakpoint, put the cursor on the line of code where you want to halt execution and click the Toggle Breakpoint button on the toolbar.

To clear all breakpoints at once including exception breakpoints in the project, click the Clear All Breakpoints button on the toolbar, or press Ctrl-F9.

## Using the Debugging Commands

Once execution is halted on a breakpoint, you can use one of the following commands to continue executing your code with the debugger. All of these commands are available on the toolbar and on the Debug menu.

- Step Into: The Step Into command continues execution line-by-line, beginning with the next line of code. Use this command if you want to debug your code one line at a time.
- Step Over: The Step Over command executes a method call without debugging that method, and halts execution on the next line. Use this command if you know that the code in a method works and you don't need to step into it.
- Step Out: The Step Out command finishes executing a method and returns execution to the procedure that called it, halting on the line immediately following the method call. Use this command if you have stepped into a method and you don't want to continue stepping all the way through it.
- Continue: The Continue command resumes execution until another breakpoint is encountered or the procedure has completed.
- Export Threads: The Export Threads command, found in the Debug menu, creates and opens a text file that contains the call stacks of all of the threads that are running. This is a convenient way to save or share the current threads in the event of a deadlock or other threading problem. The command is only active when the debugger has thread information.

Note that if you step into a line that contains more than one statement, all of the statements on that line will be executed when you step to the next line.

## Debug Windows

The debug windows provide information about values and conditions in your code while you're running it in the debugger. There are several to choose from:

- Locals Window - shows variables that are in scope
- Watch Window - displays the value of a specified variable while debugging
- Stream Window - shows output stream for JSPs
- Immediate Window - allows you to execute code while debugging
- Call Stack Window - shows the methods called to get to the point at which execution halted
- Threads Window - shows information about currently executing threads
- Breakpoints Window - lists currently set breakpoints

To view one of the debug windows, choose Debug Windows from the View menu, and select the desired window. For more detailed information about the debug windows, see Using the Debug Windows.

Related Topics

Debugging Properties

Using the Debug Windows

Working with Breakpoints

Debugging Scenarios

Working with JUnit

How Do I: Debug a Java Project?

How Do I: Debug an Application?

How Do I: Debug an Application on a Remote Production Server?