Effective Debugging: Conditional Breakpoints
One of the most important developer activities is debugging. In my college days, we were forced to use simple text editors for our software development, so I started out using print statements to see where my code was going wrong. These days, we have the comfort of IDEs, but debugging remains one of those talents that you get more efficient at with experience.
The best feature I have seen in both Eclipse and NetBeans is the conditional breakpoint concept. The idea is simple, take your breakpoint, and type in a condition for the breakpoint to stop at. For example if I have the following code:
for(Employee emp: employees)
{
if(emp.getType() == Employee.MANAGER)
{
addToManagers(emp);
}
}
Let's say that I want to see the values of all the variables when the employee's getType value is Employee.DEVELOPER, and step through to make sure that we don't enter the if statement block.
In Eclipse, you can set the breakpoint as normal on the if statement, right click on the breakpoint and you'll see the following menu:
You can now set a condition for your breakpoint in the resulting dialog by selecting the Enable Condition checkbox:
As you type in the condition you get full content assist. You can also change what this condition means - whether to stop when it's true, or when it changes since the last iteration.
In NetBeans, it's much the same. You still get the properties on right-click of the breakpoint:
The dialog is also similar with conditions and hit count, with content assist:
Things like this can really help speed up your debugging - when you know a particular value has caused your program to fail, you can get right to the heart of the matter.






Comments
Gabor Farkas replied on Mon, 2009/12/28 - 9:17am
Shay Shmeltzer replied on Mon, 2009/12/28 - 1:20pm
fred jones replied on Tue, 2009/12/29 - 1:39am
I can't believe you left out one of the most powerful features of conditional breakpoints: you can execute arbitrary code at the site of a breakpoint. I know this is a feature of the Eclipse debugger. I'm not sure about other debuggers.
You aren't limited to expressions in the condition textarea; you can put in Java statements. Often I'll put in several statements and end it with "return false;" so the debugger never stops at the breakpoint.
One example of this is adding temporary logging:
logger.debug("listLength: "+list.size());return false; //never suspend execution, just do logging
Another is changing the value of something:
Even more useful is throwing exceptions in order to test a catch block. Just because you rarely see the exception in a normal run of the application doesn't mean you can't test how it would behave if the exception were thrown:
throw new IOException("test");Using conditional breakpoints for these types of things lets you see how the application would behave if you added this code, but allows you to easily enable and disable it and do it without the risk of leaving this temporary code in your source files.
James Sugrue replied on Tue, 2009/12/29 - 5:18pm
in response to:
fred jones
Pavan Kumar Sri... replied on Wed, 2009/12/30 - 8:39am
Tommy Le replied on Fri, 2010/08/13 - 6:03am
Jason Bourne replied on Wed, 2012/11/14 - 7:05am