How debuggers saved me grey hairs...

As much as Brian wants to stick with System.outs to do debugging, I would go with a proper debugger any day.  Each time I use the IntelliJ debugger, I thank the engineers @ IDEA for putting a fantastically useful debugger into the IDE.

 

A few days ago, there was a very wierd problem where I had quickly find why a particular data element was causing a Liferay LAR file to fail to import.  The LAR had roughly 200 pages, 500 web content articles, and 200 documents.  Imagine trying to step through that many elements one at a time...

Conditional breakpoints to the rescue!

In IntelliJ, you can configure when a break point gets triggered.  For instance, I was debugging the LayoutImporter in trunk at line 778:

 

     Node parentLayoutNode = rootElement.selectSingleNode("./layouts/layout[@layout-id='" + parentLayoutId + "']");

 

With 200 different layouts, I would be clicking "proceed" a lot to find the layout I really wanted.  Instead, I define the following condition for activating the breakpoint:

  (parentLayoutId == 203990)

 

 

 By using this conditional break point, the IDE would only halt if the parentLayoutId equals 203990 and not for the other 199 layouts.  

This condition expression can contain any number of boolean expressions so this is an extremely powerful capability.

 

I'm sure you can do the same in Eclipse but I just don't know how.

[Bruno Farache]

In Eclipse it's pretty easy too! You just need to right-click on your break point and edit its properties.

I don't think bchan misses this feature:

if (parentLayoutId == 203990) {
System.out.println(...);
}

[Ryan Park]

That's really funny Bruno

[Jonas X. Yuan]

Nice! Thank you, Bruno.

[Koen De Jaeger]

Yes, it's possible in eclipse as well.
Tnx for reminding us about this useful feature.