I really like the
JDT's
Java Exception Breakpoints: Most of the time, I'm running my code from the debugger, with breakpoints set at least on
NullPointerException and
ClassCastException (through
Run > Add Java Exception Breakpoint). It brings my debugger exactly to those places where a problem occurs - and helps me to diagnose it right away.
But sometimes, the debugger breaks at unexpected places, like the following code I've seen the other day:
try {
FooManager.getFoo().execute();
} catch (NullPointerException e) {
//Nothing to execute if foo's not there yet
}
Apparently, the original developer's idea was that the FooManager might have a foo or not -- if it doesn't have one, then getFoo() returns
null and there is nothing to execute.
Now most seasoned Java Hackers may have it in their guts that this is not good code. The younger ones might know it because
Bloch writes it (
Effective Java, chapter 8, Item 39: Use exceptions only for exceptional conditions; if you haven't read this book, you
must read it!).
Bloch has some good arguments for
avoiding exceptions instead of
catching them. But using exception breakpoints, here is another just practical one - it breaks the debugger where it's not necessary, because the code does run as intended. So I've changed the code:
Foo foo = FooManager.getFoo();
if (foo!=null) {
foo.execute();
}
Now that's even shorter (4 lines of code instead of 5), clearer to understand, and my Debugger won't need to get active... so in the future, I'll live with
Catch me if you can't avoid me - which might have made the life of
Tom Hanks easier too...
![[RSE Sample Screenshot]](http://www.eclipse.org/dsdp/tm/images/RSESample.gif)
