Checked Exception Patterns

CheckedExceptionsAreOfDubiousValue in Java: they create lots of dependencies and the type information they convey only serves two purposes: as documentation about what sort of exception handlers to write in the rare case that types of exception need to be distinguished and as a notification that an exception can propagate out of the method. Of these two only the second is indispensable for writing correct programs.

Exception handlers are rare. They appear either very close to the UI or very close to some sort of system boundary that requires error information to be marshaled so it's usually best to SeparateThrowAndCatch. For maximum flexibility and to implement a uniform exception handling policy, it's best to UseIdenticalExceptionHandlers everywhere in a subsystem. This is flexible because both the exception handlers and the exception throwers are coupled to the pool of available exception types (a fairly stable abstraction) but not to each other. The disadvantage is some duplicated code in all of the handlers. In practice, this code is easy to maintain because it is fairly stable and easy to find.

Methods that contain exception handlers aren't the only ones that need to be aware of propagating exceptions. Propagating an exception is equivalent to aborting a database transaction [ThrowIsRollback?]. All the work done starting from the initial call in the "try" clause up to the point of the exception throw should be rolled back to its initial state, or in the worst case rolled forward to some stable state. In order to write code that is exception safe an author needs to know which methods might throw exceptions, so that the rollback code can be put into a finally clause, and, which methods cannot throw exceptions and are therefore safe to call after rollback becomes impossible. The latter sort of methods are critically important to writing correct programs. It would be a grave error to create a method that doesn't throw exceptions, use it in a situation where exceptions aren't tolerated, and then change it so that it does throw an exception. (DeclareThrowsExceptionByDefault)

Methods that MUST NOT throw exceptions are declared without a "throws" clause (if it were my language to write you'd have to specify something special for a method that DOESN'T throw rather than one that does). If you need something more specific than "throws Exception" then put it in - it hasn't happened to me yet so I can't be more specific. If it happens that a method doesn't actually propagate any exceptions and you need to use it in a situation where it won't be allowed to, then remove the "throws Exception" clause. Having to rewrite a non "throws Exception" method so that it does throw is a big deal because all of its clients have to be checked and possibly rewritten.

My exception handlers almost always either translate the exception into some other form of error for further propagation or they ask the end user to make a decision about how to proceed. I anticipate that, on occasion, I'll write exception handlers that try an alternate strategy to accomplish the original task, but I have not yet had the opportunity to do so.

CategoryException

CategoryJava