> In my experience many C# programmers simply fail to add much exception handling code at all because the compiler doesn't force them to.
Still better than:
try {
// Do broken stuff
} catch (Exception e) {
throw new RuntimeException(e); // TODO: Add a domain-specific runtime exception so we can actually catch this
}
I find this or something like it[0] spread across every Java codebase I find myself mired in, and I read a lot of Java these days (much to my dismay, but so it goes).
[0]: Actually, that's not fair. Most people don't bother to include the TODO.
You meant to say "catch (Throwable e)", right? But, yeah, I've had to write that block too many times.
Throwable will catch Errors as well as Exceptions, such as when a constructor called from a dependency injection framework fails. It's kind of irked me for a while that I had to know that. I would have rather had "catch" work on anything, with the option to check the class and rethrow once in a great while. That is, in the few places where the error checking/logging actually belongs (as stated in the article, with which I obviously agree).
There is indeed great irony in Java code littered with catches, which then falls out and kills the main loop without logging anything. (I recently had to diagnose such a case in a system at work over the phone -- sure enough, that's exactly what was coded)
You are not supposed to, and don't need to, catch Errors. The only exceptions you need to worry about as far as checked exceptions go are classes that inherit from Exception but not RuntimeException.
Still better than:
I find this or something like it[0] spread across every Java codebase I find myself mired in, and I read a lot of Java these days (much to my dismay, but so it goes).[0]: Actually, that's not fair. Most people don't bother to include the TODO.