Method breakpoints allow the user to see when a method is entered or exited.
Open the
SampleHandlerclass, 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 the method entry and method exit.
Click the Hello World icon again.
When the debugger stops at the method entry, click on the Resume icon.
When the debugger stops at the method exit, click on the Resume icon.
The breakpoint triggers at the time the method enters and subsequently when the method's return statement is reached.
Note that the exit is only triggered if the method returns normally; if an exception is raised which causes the method to return, this is not treated as a normal method exit, and so the breakpoint won't fire.
Other than the breakpoint type, there's not a significant difference between creating a breakpoint on method entry and creating one on the first statement of the method. Both give the ability to introspect the parameters and do further debugging prior to any statements in the method itself are called.
The method exit breakpoint, on the other hand, 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 to the line breakpoint, which will wait to evaluate the argument of the return statement.
Note that Eclipse's Step Return 
icon 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 clicking on Step Return.