Java supports checked exceptions and C# doesn’t. A friend and I had a conversation earlier this morning about whether it’s a minus for a programming language to lack check exceptions.
My point of view
I’m not sure it’s the wrong decision, to not support checked exceptions… I think the key is for the code to document which (unchecked) exceptions it specifically throws.
What we want:
- To have the ability to handle exceptions we know what to do with
- Not to be forced by code we call to handle exceptions we may wish to let percolate on up the call stack.
If the third-party library throws checked exceptions it FORCES the calling library to do something (if only explictly ignore), which violates the second requirement. A given block of code should only do something with an exception if it knows what to do with it, otherwise it should percolate up to someone who does know what to do with it. The checked exception mechanism interferes with this by forcing each caller to deal with the exception explicitly — not insurmountable, but less clean.
If library code doesn’t document the (unchecked) exceptions it throws, that would violate the first requirement, prevent good caller handling and be bad.
I think both requirements are important — that’s why I think checked exceptions are the wrong thing.
Who owns this decision?
By saying we don’t want to be forced by code we call to handle exceptions we may wish to let percolate on up the call stack I’m not saying we want to leave exceptions unhandled that we should be handling — I’m not saying I want the app to unexpectedly crash in production. I guess what I’m really getting at is that I think the decision of which exceptions must be dealt with should be made by my application’s business logic, not the author of the library I’m using. Why is it Sun that gets to make the decision that this particular IOException must be dealt with by the caller? (Again, even if only by passing the buck to its caller — my point being you have to add explicit code to do something.)
An Analogy
This reminds me of an accounts receivable system that has persons, accounts, and relationships between the two.
Certain information is attached to each person — a first name, for example.
Certain other information is attached to each account — its balance, for instance.
But there is some information that doesn’t pertain directly to a person nor an account — for instance, whether the person is legally responsible for the balance on an account. Legal responsibility isn’t a property of a person, surely (if so, then once your “legally responsible” flag was set, you’d be seen as legally responsible for all accounts you’re associated with — even if on certain accounts you were only listed as a contact). And of course accounts aren’t legally responsible. But a person is either responsible or not for a given account with which they’re associated.
It seems to me that with Java’s checked exceptions, the “exception must be handled ” property has been placed in the wrong hands — in the library developer’s instead of the application writer’s. It feels like we’re placing the “legally responsible” property on the person.
A Softening?
The Spring framework wraps many Java checked exceptions with unchecked exceptions. I searched their site for a written philosophy of checked versus unchecked exceptions, thinking I might find a categorical “checked exceptions are evil” statement with which to buttress my argument. Instead I found this, in the Spring mission statement:
We believe that…checked exceptions are overused in Java. A platform shouldn’t force you to catch exceptions you’re unlikely to be able to recover from.
I think highly of the design decisions I’ve seen coming from the Spring group, so this more nuanced answer carries weight with me.
Maybe there’s still a proper place for checked exceptions, then…
But still, is the library author the right one to decide which “exceptions you’re unlikely to be able to recover from”?
Hmm.
References
- The Trouble with Checked Exceptions — artima.com
- A Comparison of C# to Java — 25hoursaday.com
- Directing Attitude vs. Enabling Attitude — Martin Fowler’s bliki
Our Craft 