Dead Horse: Checked Exceptions

I'm reading "Beyond Java", by Bruce Tate, and he complains as many have about checked exceptions. I've never understood this complaint, and I don't want to say that it's because I understand how to use them and all these smart people don't, but I'm about to.

I like checked exceptions, they keep me honest. Tate asserts in many places in his book that the few actual problems that static typing catches would be caught with unit tests anyway, but this seems like a case where you can't make that argument anymore. In the unit tests I write and read, failure cases are the least well handled.

Tate (and others) asserts that checked exceptions are invasive, and continues to say that most of the time you can't do anything but throw it, so you're always throwing them, and eventually you just ignore anything you read that has exception in it.

He's right, about that part. The problem that I see is that it's never led him to used checked and unchecked exceptions together. Here's how I evaluate whether to handle, re-throw or convert an exception:


1. Can I handle it? Obviously, if I can, I do.
2. Will callers be able to handle it? Then let them.
3. If callers can't handle it, is it imperative (due to data corruption) that callers be aware of this situation?
4. If none of the above, turn it into a Runtime Exception.

These questions are asked at integration points, like the barrier between a webapp and the database, a property loader and the filesystem, or a utility program and a webservice. If we had no checked exceptions, I feel pretty confident that I would fail to consider all the potential failures in these integration points, and have far less robust code as a result.