« A troll from the server side | Main | REST and session state »

Exceptions considered pointless

Three rules of thumb are forming in my mind around exceptions:

  • don't swallow exceptions (with two exceptions)
  • avoid using exceptions
  • avoid inventing exceptions

The first many Java developers will understand. Rarely, you know an exception is not going to be thrown, but you have to catch it anyway, and sometimes you have to catch InterruptedException as part of normal program flow.

The last two are maybe controversial.

I've never found knowing the type of exception as useful as the actual execution trace or the messages held in the exception. Usually, the package or domain of the exception, is far less interesting information than the nature of the failure. I don't care that it was a SAXException or an JMSException that got thrown, I care about the nature of the violation that caused the exception. What constraint or assumption was broken? Also having written a good bit of multithreaded and distributed/server Java code in the past, slinging exceptions about tends to be less useful and less robust than designing with partial failure cases as being normal. Protocols, not exceptions, rule when it comes to bits on the wire.

And in code, most of the time, exceptions are pure line noise. It seems OO developers have real problems designing good exception hierarchies - I suspect this because exceptions are really about execution flow and runtime behaviour, whereas OO is slightly more static, being about managing dependencies and code organization. You can't really slice up error handling into package structures and APIs the way you can Java objects, though heaven knows lots of people try to do just that (I suspect a useful side effect of the rise of AOP frameworks will be to eradicate many checked exceptions from Java).

For all the said benefits of exceptions I honestly think 90% of my coding could be done with less than a dozen types, most of which are in the JDK proper. Recently I've been finding Exception is perfectly adequate for a lot of of code; in the past I'd be scratching my head wondering what type to throw. Having said that, I would prefer a totally different system of exceptions, oriented around forms of failure instead of packages and APIs, but there's zero chance of that happening at this stage in Java's development. Today most of my headaches are dealing with third-party exception models, which do a lot to wriggle their way into my code, but very little to tell me what actually happened.

January 28, 2003 10:56 PM


bob mcwhirter
(January 29, 2003 07:15 AM #)

I truly think that the idiom of using String messages as parameters for an exception and the getMessage() method have contributed to the uselessness of many exceptions. You're right that we all tend to getMessage() or printStackTrace().

I wouldn't say our exceptions are poor, but that our exception handling is. I try very hard to have meaningful constructors with meaningful parameters, and no messages, in my Exception hierarchy.

public class NoSuchThingException
extends Exception
public NoSuchThingException(ThingRepo repo, String thingId) { ... }

public ThingRepo getThingRepo() { ... }
pulibc getThingId() { .... }

The getMessage() is implemented in the class, and constructs a message using the accessors to the parameters of the constructor.

So, my exception attempts to provide enough -context- to gracefully handle the exception. When all you get from your Exception is a String message, you have few options.

With member data, your handling capabilities expand, and the usefulness of exceptions as a whole increases.

If you really think exceptions are pointless, always throw a RuntimeException. You can still catch them when you need to, but otherwise, you can completely ignore them and have the JVM bomb out with the stacktrace you want.

Dave Ely
(February 2, 2003 10:09 AM #)

Bill, I've posted a reply on my weblog where I pretty much agree with Bob completely regarding string based exceptions.


Trackback Pings

TrackBack URL for this entry: