97 Things Every Java Programmer Should Know

Chapter 85. Uncheck Your Exceptions

Kevlin Henney

If you ever want to walk to hell, the journey will be easy on your feet. The whole road is very well paved, with good intentions as far as the eye can see. At least one of those paving stones is dedicated to Java’s checked exception model.

A checked exception is one that, if not handled within a method, must appear in the method’s throws clause. Any class descended from Throwable can be listed after throws, but unhandled checked exceptions (not descended from either RuntimeException or Error) must appear. This is a feature of the Java language, but it has no meaning for the JVM and is not a requirement for JVM languages.

The good intention here promotes a method’s failures to the same type-level significance as its success-scenario inputs and outputs. At first sight, this seems reasonable. Indeed, in a small and closed codebase, this type-level confidence that some exceptions are not overlooked is an easy goal to meet and, once met, offers some (very) basic reassurance about the completeness of the code.

Practices that might work in the small, however, are under no obligation to scale. Java’s checked exceptions were an experiment in combining control flow with types, and experiments produce results. The designers of C# learned from the experience:

C# neither requires nor allows such exception specifications. Examination of small ...