Time for action – setting up step filtering

Step filters allow for uninteresting packages and classes to be ignored during step debugging.

1. Run the target Eclipse instance in debug mode.

2. Ensure that a breakpoint is set at the start of the execute method of the SampleHandler class.

3. Click on the hello world icon, and the debugger should open at the first line, as before.

4. Click on Step Into five or six times. At each point, the code will jump to the next method in the expression, first through various methods in HandlerUtil and then into ExecutionEvent.

5. Click on resume to continue.

6. Open Preferences and then navigate to Java | Debug | Step Filtering. Select the Use Step Filters option.

7. Click on Add Package and enter org.eclipse.ui, followed by a click on OK:

   

8. Click on the hello world icon again.

9. Click on Step Into as before. This time, the debugger goes straight to the getApplicationContext method in the ExecutionEvent class.

10. Click on resume to continue.

11. To make debugging more efficient by skipping accessors, go back to the Step Filters preference and select Filter Simple Getters from the Step Filters preferences page.

12. Click on the hello world icon again.

13. Click on Step Into as before.

14. Instead of going into the getApplicationContext method, the execution will drop through to the getVariable method of the ExpressionContext class instead.

What just happened?

Step Filters allows uninteresting packages to be skipped, at least from the point of debugging. Typically, JVM internal classes (such as those beginning with sun or sunw) are not helpful when debugging and can easily be ignored. This also avoids debugging through the ClassLoader as it loads classes on demand.

Typically it makes sense to enable all the default packages in the Step Filters dialog, as it's pretty rare to need to debug any of the JVM libraries (internal or public interfaces). This means that when stepping through code, if a common method such as toString is called, debugging won't step through the internal implementation.

It also makes sense to filter out simple setters and getters (those that just set a variable or those that just return a variable). If the method is more complex (like the getVariable method previously), then it will still stop in the debugger.

Constructors and static initializers can also be filtered specifically.

Using different breakpoint types

Although it's possible to place a breakpoint anywhere in a method, a special breakpoint type exists that can fire on method entry, exit, or both. Breakpoints can also be customized to only fire in certain situations or when certain conditions are met.