The Path to Zen

My 2 Cents on Checked Exceptions

This might sound philosophical and irrelevant, but hear me out - the biggest problem I have with checked exceptions is that they are way too prescriptive. When we say “checked exceptions force themselves to be handled,” that’s an understatement of the prescriptiveness. What’s worse is actually that checked exceptions impose this forcement on the immediate caller.

So what are the practical issues caused by this overly strong prescriptiveness? After all, we are subject to all kinds of prescriptive annoyances in our daily programming life (and perhaps non-programming life also for that matter). If it’s just some philosophical thing, why bother, right?

Well, it’s inconsistent in programming practices, to begin with. Let’s say we have a method int foo(). In one particular usage scenario we don’t really care much about the return value of foo(), so we would simply put foo();. But you can’t completely ignore it if foo() throws a checked exception. At least you have to try/catch or rethrow it, point here being the immediate caller must be aware of the presence of that exception. What if the next version of javac makes foo(); illegal, and enforces that any method with non-void return type must have its return value assigned to a variable? Most of us would no doubt think that’s just ridiculous, and yet we somehow consider it’s reasonable to mandate the handling of checked exceptions, which in some broad sense are just return values.

And speaking of return values, that leads to another practical issue. We all know about the notorious flame bait called “should XXX be in the return value or an exception?” IMHO, checked exceptions, if not the root cause of that big confusion, have definitely been fueling it by blurring the distinction between return values and exceptions. People have much less problem determining whether XXX should be a return value or an unchecked exception. Why? Because the nature of unchecked exceptions carries a clear message that they are unexpected, and completely out of band - which is what all the exceptions should have been, per the very definition of word “exception” itself. So it’s that much easier to look at getAccount() and decides that it should return null instead of throwing AccountNotFoundRuntimeException, because “account not found” should be expected. On the other hand, since AccountNotFoundException must be handled by the caller - and hence must be fully expected by the caller, we now have two options to return a piece of information back to the caller, and both are equally effective in keeping the caller’s “level of expectation”. When there are more than one option and none is obviously better than others, guess what, there’s gonna be some debate.