Time for action – breaking at method entry and exit
Method breakpoints allow the user to see when a method is entered or exited.
- Open the
SampleHandler
class, and go to theexecute
method. - Double-click in the vertical ruler at the method signature, or select Toggle Method Breakpoint from the method in one of the Outline, Package Explorer or Members views.
- The breakpoint should be shown on the line:
public Object execute(...) throws ExecutionException {
- Open the breakpoint properties by right-clicking on the breakpoint or via the Breakpoints view, which is shown in the Debug perspective. Set the breakpoint to trigger at method entry and method exit.
- Click on the hello world icon again.
- When the debugger stops at method entry, click on resume .
- When the debugger stops at method exit, click on resume .
What just happened?
The breakpoint triggers at the time the method enters and subsequently when the method's return
is reached. Note that the exit is only triggered if the method returns normally; if an uncaught exception is raised, it is not treated as a normal method exit, and so the breakpoint won't fire.
Other than the breakpoint type, there's no significant difference between creating a breakpoint on method entry and creating one on the first statement of the method. Both give the ability to inspect the parameters and do further debugging before any statements in the method itself are called.
The method exit breakpoint will only trigger once the return
statement is about to leave the method. Thus any expression in the method's return
value will have been evaluated prior to the exit breakpoint firing. Compare and contrast this with the line breakpoint, which will wait to evaluate the argument of the return statement.
Note that Eclipse's Step Return has the same effect; this will run until the method's return statement is about to be executed. However, to find when a method returns, using a method exit breakpoint is far faster than stopping at a specific line and then doing Step Return.
Using conditional breakpoints
Breakpoints are useful since they can be invoked on every occasion when a line of code is triggered. However, they sometimes need to break for specific actions only—such as when a particular option is set, or when a value has been incorrectly initialized. Fortunately, this can be done with conditional breakpoints.