This funny brush with infamy reminds my of another blog I saw the other day. I found a link to Jason Salavon's blog and his blurry playmate retrospective. It turns out Dave Barry did the same thing and had a few ' snarky' words on the subject. Its funny, you never know who will read you're blog and think you're and asshole.

• Experience
• Seamless
• Consuming
• Scenarios
• Extreme (the irony was noted)
• Market Segment
• Enthusiast
• Lifestyle
• Digital Home

• Heterogeneous
• Provisioning
• Silo
• Horizontal
• Vertical
• Federated

The researchers posit that material ejected from the companion star, its so-called stellar wind, is accreted by the black hole to form a dense shell around the pair.

Probably the main reason people don’t do this in Java is because the Exception class doesn’t provide any default mechanism for storing extra data. To that end I wrote some new Throwable base classes for my project at work that allow arbitrary annotations to be attached to an exception before it’s thrown. (I call them AntException, AntRuntimeException, etc….). Not only can I annotate the exception with contextual data, I can mimic the Java 1.4 feature of chained exceptions in Java 1.3 by annotating an exception with another exception.

The problem is that most people are thinking about the non error path when they write the code and not about how they will debug a post-mortem problem in the code from a log file. A very simple case of how doing this little extra work has helped is this story. I work on a very large team spread literally across the world. On any given day there are people running any of a half dozen builds from the past week. As exceptions show up in the log, folks capture the log fragments and write bug reports (or Software Problem Reports as we call them). One very simple thing we did to make this information more valuable was to annotate every exception with a build version number. (Sure the tester should know what version of the code they are running and put that in the bug report, but this eliminates any doubt). So now when I look at an exception dump in a log file I not only know where the problem occurred, but what build it was that had the problem.

My second criticism is the statement "They create too many possible exit points". There is nothing that says a method needs to throw exceptions from multiple points anymore than you need to return from multiple points. The same techniques you use to manage the number of returns can be used just as well with throws. In Java you don't even have to worry about this because you can do all your cleanup in the finally block.

I don't pretend to love everything about working with exception based error handling code, but the idea that returns codes are a better tools is just plain wrong.