Exception Guidelines

Contingencies and Faults

The following concepts of contingency and fault is derived from Barry Ruzek's Article ''Effective Java Exceptions'' and it is advised that developers atleast skim it.

Grossly oversimplified picture in a nutshell: A contingency is a control-flow related checked exception. A fault is an unexpected RuntimeException or Error that does not relate to the workflow of the class/method/application. Faults subclassing Error are generally signs that the entire JVM might be compromised (see also javadoc for the Error class) and should as a rule of thumb not be caught (except possibly by the outermost fault barrier).

The following table is copied from Ruzek's article:




Is considered to be

A part of the design

A nasty surprise

Is expected to happen

Regularly but rarely


Who cares about it

The upstream code that invokes the method

The people who need to fix the problem


Alternative return modes

Programming bugs, hardware malfunctions, configuration mistakes, missing files, unavailable servers

Best Mapping

A checked exception

An unchecked exception

A fault barrier is a conceptual layer in the control flow where certain kinds of faults are caught. It is a perfectly acceptable fault barrier to catch general Exceptions, used for example to encapsulate unreliable subsystems. It must be specified in the javadoc of a method that it acts as a fault barrier and what the intended purpose of the fault handling is (including the types of faults it handles).

Best Practices


NOTE: To enforce that we minimally log exceptions at the root of a thread we could use Thread.setDefaultUncaughtExceptionHandler.



Throwing Exceptions

Generally don't log when throwing exceptions. Instead make sure to put a good error message in the exception. Good error messages include as much context as reasonable. For example

        for (Record rec : database) {
                if (rec.length == 0) {
                        throw new EmptyRecordException ("Record " + rec.getId() + " was empty");

Rethrowing Exceptions

Rethrowing exceptions is fine, as long as the old Exception is wrapped in a new Exception as this preserves the stack trace. Follow the guidelines from the throwing exceptions chapter above.

        try {
        catch (IOException e) {
                throw new RecordWriterException("Could not store the record '" + rec.getId() + "' to file '" + filename + "'", e);

ExceptionGuidelines (last edited 2010-03-17 13:13:02 by localhost)