Posted in
Tips
All of know the importance of the breakpoints during debugging. But do you know apart from setting a breakpoint on a line, there are other ways to set a breakpoint? Lets explore the breakpoints supported by Eclipse.
- Line Breakpoint
- Exception Breakpoint
- Classloading Breakpoint
- Watchpoint
- Method Breakpoint
- Printpoint
Line Breakpoint
This is the simplest breakpoint that everyone knows about. Double click the ruler and a breakpoint is set. Whenever that particular line is executed, the breakpoint is hit. If you want the breakpoint to be hit only certain conditions are met, then you can specify it in the breakpoint properties.
Exception Breakpoint
When exceptions are passed over several layers, they are often wrapped or discarded in another exception. When you want to find out the origins of the original exception, then the Exception Breakpoint will help you. Once you add a breakpoint on an Exception (The action is available the Breakpoints view toolbar), the execution will be suspended whenever this Exception is thrown or caught.
Class Load Breakpoint
If you have troubles with classloading this might come handy. Double click the ruler in the line the class is defined. You will get a Classloading Exception. When the class is loaded, the breakpoint is triggered and you can inspect who is trying to load this class (or where is it used for the first time)
Watchpoint
You have a field, which is initialized to some value in the constructor. But during execution, you hit an NPE on that field. There are numerous places where it could have been changed and it would be a hard task to find all the places, set a breakpoint and then debug it. A Watchpoint on that field comes handy. You can break the execution not just the places where the field is modified, but also in the places where it is accessed. To add a watchpoint for a field, again double click the ruler on the line where it is declared.
Method Breakpoint
Not just fields, even methods can have a breakpoint. Again, double click the ruler, you get a method breakpoint. Now everytime this method is executed, the breakpoint will be hit. At a glance, this might sound like a useless thing, as you can always set a line breakpoint on the first line of a method. But this can break the execution even when the method exits. So if your method spans for 2000 lines with two dozen returns in there, this breakpoint is very useful to find out where and what is being returned from the method.
Printpoint
When you are able to reproduce a problem when running, but not debugging, then its potentially a race condition in a multithreaded app. Because you hit a breakpoint, you suspend that thread by default and the other threads might keep executing. It will be near to impossible to debug it and the only way to trace the race condition is to modify the code and insert sysout statements. Enter printpoint, you don't have to modify the code to do this. This is essentially a conditional breakpoint (either a Method Breakpoint or a Line Breakpoint), which has "return false" as the last statement in the condition. In this way, you get to execute the code in the condition clause, but don't have to break the execution. I wish I knew this feature when I was debugging a server bug in my previous job :-(
| < Prev | Next > | |
|---|---|---|
