Eclipse Zone is brought to you in partnership with:

I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Effective Debugging: Conditional Breakpoints

12.28.2009
| 45437 views |
  • submit to reddit

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.

 

 

5
Your rating: None Average: 5 (2 votes)
Tags:

Comments

Gabor Farkas replied on Mon, 2009/12/28 - 9:17am

Agreed, this is a really useful feature in our IDE-s. I'd just like to add some more tips:
  • Conditional breakpoints can slow down the program execution quite much. In such case, I put a non-conditional breakpoint to the closest point I want to catch, and then enable the conditional breakpoint - if possible.
  • When finished debugging, don't forget to remove all your breakpoints and watch expressions. They also slow down the execution, and forgotten watch expressions can change the execution when you're debugging some other thing.

Shay Shmeltzer replied on Mon, 2009/12/28 - 1:20pm

Also available in JDeveloper: http://www.java-hair.com/?p=61 http://www.oracle.com/technology/products/jdev/howtos/10g/threaddebugging/index.html

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:

if(value==null) value="";
return false;

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

That is a pretty cool addition alright - thanks for the tip.

Pavan Kumar Sri... replied on Wed, 2009/12/30 - 8:39am

Eclipse still  has no support for Dependent Breakpoints ...unlike IDEA

Tommy Le replied on Fri, 2010/08/13 - 6:03am

Hey, I encountered this problem: Eclipse debugger stops at a random line which doesn't have any breakpoints. Google pointed out to an uncaught exception, but it's not my case. Assuming you master the debugger, could you pls help me resolve this? Thanks.

Jason Bourne replied on Wed, 2012/11/14 - 7:05am

Some of what I have written about is state-of-the-art, and you might not even find it on the usual pro-tech or transhumanist websites like kurzweilai.net, hplusmagazine.com or acceler8or.com. e.g. I recently wrote about unsupervised semantic parsing (and indirectly about unsupervised ontology induction), which is a BIG BIG DEAL in A.I. research... but is not exactly the sort of thing you will see discussed on kurzweilai.net, for instance. Click here 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.