Designing With Exceptions

This conclusion came from an article in the 7/98 issue of JavaWorld, and was not posted by the author.

The original article by BillVenners is located at http://www.javaworld.com/jw-07-1998/jw-07-exceptions.html

Designing with exceptions[1]

Guidelines and tips on when and how to use exceptions

By BillVenners

Concludes:

: "The most important point to take away from this article is that exceptions are there for abnormal conditions and shouldn't be used to report conditions that can be reasonably expected as part of the everyday functioning of a method. Although the use of exceptions can help make your code easier to read by separating the "normal" code from the error handling code, their inappropriate use can make your code harder to read."

Here is a collection of the exception guidelines put forth by this article:

If your method encounters an abnormal condition that it can't handle, it should throw an exception.
Avoid using exceptions to indicate conditions that can reasonably be expected as part of the normal functioning of the method.
If your method discovers that the client has breached its contractual obligations (for example, by passing in bad input data), throw an unchecked exception.
If your method is unable to fulfill its contract, throw either a checked or unchecked exception.
If you are throwing an exception for an abnormal condition that you feel client programmers should consciously decide how to handle, throw a checked exception.
Define or choose an already existing exception class for each kind of abnormal condition that may cause your method to throw an exception. (But keep in mind the exception should reflect the reason of the problem instead of the operation causing of the problem, i.e., FileNotFoundException? or DuplicateKeyException? instead of CreateException? from a create() method. You can already see it is coming from the create() method in the stack trace)

I'd like to weigh in here with a controversial opinion: I really don't like checked exceptions. I think that they introduce an undesirable dependency between the implementation details of a service providing method and its clients. My experience has been that the fewer exception handlers there are in a system the more powerful exception handling becomes. That means exceptions will propagate further which means more throws clauses for checked exceptions. It is better in my mind to leave exception throwing and handling up to the code that is actually doing the throwing and handling and leave the rest of the code out of it. -- PhilGoodwin

I've heard this opinion other places, and while I see where you're coming from (HOW many places do I have to catch RemoteException?), in general, I'm glad exception checking exists.

Knowing what could go wrong when a method is called helps me decide which of those cases my method can or should handle.

One argument against checked exceptions is that they propagate to places they shouldn't. Suddenly the methods to access a conceptual thing that happens to read from a file are full of IOExceptions (ditto for RMI). However, I think this is the wrong approach. The trickiest thing about dealing with checked exceptions is when to convert them. In the example I mention, the method that loads the class initially should throw IOException, but the other methods have, as a part of their contract, the expectation that the file exists, etc. etc. These methods should convert the IOException to some other (probably application-specific) RuntimeException that is (presumably) caught at the highest level.

-- Kevin Klinemeier

CategoryException