Working with Breakpoints

Breakpoints can be set

• To halt the execution of code (line or taglib breakpoints)

• When a method is executed (method breakpoints)

• When an exception occurs (exception breakpoints)

Each type of breakpoint is described in detail in the following sections.

Line and Taglib Breakpoints

When you encounter an error in an application's response, your immediate task is to find the code responsible for the problem. One way to detect the code is to halt the application's running at the points suspected of causing problems. To help you do this, Workshop Debugger provides line breakpoints ; the application halts at these breakpoints when running the code. This gives you an opportunity to examine the different parts of the application, such as variable values, running threads, and executed methods . Eventually, examining this information enables you to discover the code responsible for breaking the application.

In the Model-View-Controller (MVC) pattern, if line breakpoints are used to debug the View component, which is a JavaServer Page (JSP), browser caching is turned off during debugging. If a taglib is used in the JSP, you could set a taglib breakpoint that allows stepping through the code in the tag class.

To set a line breakpoint, follow these steps:

1. Click on the Source View tab.

2. Put the cursor on the line where you want to set or remove a breakpoint.

3. Click the Toggle Breakpoint button on the toolbar.

Setting a taglib breakpoint requires the following steps:

1. In the Source View, right-click on the taglib tag.

2. Choose Taglib Breakpoint from the pop-up menu.

3. In the Taglibs Breakpoints dialog box (see Figure 5.2), select the methods to set the breakpoints.

   Figure 5.2. Setting a taglib breakpoint.

   

Workshop provides other ways to set or remove a line breakpoint:

• By pressing F9

• By clicking on the gray margin to the left of the line numbers

• By right-clicking on the line and selecting Toggle Breakpoint.

SHOP TALK : DEBUGGING POINTBASE

The code is not the only part of the application you might need to debug. The Model part of the MVC pattern, where the data is stored, might also require debugging to help you ensure that the data manipulation is correct.

PointBase, a local database installed with WebLogic Platform, facilitates data storage. The following paragraphs briefly explore the features PointBase offers to help debug the back-end tier .

When you start PointBase, a command window opens. You can specify the /d: <level> (level can be 0 to 3, with level 3 displaying the most details) option in the startup script, as shown in the following code, to indicate what information should be displayed in the command window:

 "%JAVA_HOME%\bin\java" com.pointbase.net.netServer /port:9092 /d:3 /pointbase.ini="%SAMPLES_HOME%\domains\examples\pointbase.ini" 

Yet another way to debug the data stored in PointBase is by using PointBase's user interface. To do this, enter startpointbaseconsole at the command line, or simply click Start, Programs, BEA WebLogic Platform 8.1, Examples, WebLogic Server Examples, PointBase Console.

Method Breakpoints

Frequently, instead of halting the code at a particular line, you might want to halt execution at the start of a method and step through it, observing the values of the different variables used in it. To do this, you can use method breakpoints , even with overloaded methods. However, there are two options in these cases:

• Breakpoints can be set on all the methods.

• Breakpoints can be set only for a specific overloaded method based on the argument list.

To set a method breakpoint, follow these steps:

1. Choose Debug, Create Breakpoint from the Workshop menu.

2. Select the Method radio button in the Create Breakpoint dialog box.

3. Enter the fully qualified class name where the method belongs.

4. Specify the method name.

Figure 5.3 shows an example of setting a breakpoint on the checkapproval method.

Figure 5.3. Setting a method breakpoint.

For overloaded methods, include the argument list with the method name to restrict setting the breakpoint to that one method.

Exception Breakpoints

Because exceptions are where you specify the behavior that should occur in the event of an error, exceptions are a key area to set breakpoints when debugging an application. Workshop enables setting breakpoints on an exception or any of its subclasses. Three choices are available when setting an exception breakpoint:

• The breakpoint always needs to be hit when an exception occurs (for caught and uncaught unexceptions).

• The breakpoint should be hit if the exception is caught (for caught exceptions).

• The breakpoint should be hit only if the exception is not caught (for uncaught exceptions).

Follow these steps to set an exception breakpoint:

1. Choose Debug, Create Breakpoint from the Workshop menu.

2. Select the Exception radio button in the Create Breakpoint dialog box.

3. Enter the fully qualified class name of the exception (see Figure 5.4).

   Figure 5.4. Setting an exception breakpoint.

   

The Clear All Breakpoints command enables you to permanently clear all breakpoints, which you can also do by pressing Ctrl+F9. To temporarily remove breakpoints, you can disable them rather than clear them and enable them again when you need them later. To do this, select Disable All Breakpoints or Enable All Breakpoints from the Debug menu.