An Uneducated View of Checked vs. Unchecked Exceptions

Lately, I've been reading up on the raging debate surrounding exceptions and exception handling.  Specifically, how useful is it that languages like Java have checked exceptions that the caller is forced to handle?  Is it better to eliminate these and have only unchecked exceptions?

I don't write much Java.  I'm all about dynamic languages (hence the Uneducated tag).  But sometimes I have an opinion on things I don't know a whole lot about.  So here are my thoughts.

I ran across a proposal to eliminate checked exceptions in Google's experimental noop language.  I think this is a good forum to discuss the issue because the language doesn't have any baggage that comes with worries about backwards compatibility and that type of thing.  We can talk about the problem that checked exceptions try to solve and thus think of new ways to approach that problem.

Anyway, I left a comment there and I'm just going to reproduce it here for posterity and possible discussion:

I've been reading a lot about checked vs. unchecked exceptions lately. This isn't my field, but I'd just like to offer some questions/comments.

Quick question. With the above proposals (original and gabrielh), how would unhandled runtime exceptions propogate? Since they aren't explictly thrown, they're just set as scope variables.

Some people argue for specific exception types. But in my experience, most calling code trys to discern 1 thing. Is it a problem I can recover from or not? To try and clarify a little:

• The caller can't recover from a file not found error. You could suggest that the caller may be able to create the file, but that's probably giving the caller too much responsibility. Essentially another code path should be started that may eventually culminate in calling the function again. But the original path is essentially dead in terms of exception handling.

• A caller can recover from a Timeout exception in a network call. The method is idempotent in most cases, so it can just call again (and hope it was just a hiccup). Or it can pass a higher timeout. I think these are reasonable actions that are still within the caller's responsibility. If these don't work, it's time to execute another code path or propogate the exception.

So in my line of thinking, checked exceptions force a caller to consider whether it can handle any problems up front. You're more likely to include exception handling code because it's part of fulling the method signature. Only we've seen in practice that this is not the case. In many cases, the try/catch structure encourages programmers to treat all exceptions as "unfixable". Basically instead of handling the exception, most try/catches do one of the following.

• Clean up before re-throwing
• Wrap the exception in your own to throw down the stack
• Ignore It

So if you buy all of this (and I'm not sure i do, this is just a line of thought) it looks like checked exceptions aren't that helpful. But having a mechanism for explicitly specifying the exceptions that are possible is very helpful.