Exceptions for action

Exception design for efficient error handling

1 2 3 4 Page 2
Page 2 of 4

Common practices to avoid

It is possible to satisfy the above requirements with a limited set of exceptions. When designing such an exception set, you will want to avoid a number of common practices. For instance:

  • Defining an exception class for each issue that may arise in the system tends to exception proliferation.
  • Defining a complete exception set in each package is not always useful and also encourages exception proliferation.
  • Providing both a checked and a non-checked version of an exception introduces exception overhead. The subsequent duplication of exception semantics also makes for a confusing exception design.
  • Finally, throwing and catching generic exceptions is error-prone in many aspects.

The exception set I propose in the next section dispatches error-handling semantics in such a way as to avoid these common problems associated with exception handling, especially when applications grow in size and complexity.

Design for action

Figure 1 shows an exception set designed to avoid exception multiplication, checked-exception overhead, and silent catching.

A sample exception set.
Figure 1. A sample exception set (click for a larger image)

You will note that some of the exceptions in Figure 1 are checked, while others are runtime. To avoid the throw-declaration overhead, checked exceptions are limited to two purposes:

  1. Telling a calling method that an exceptional but foreseen condition occurred during processing. In this case, the semantics of the issue is defined by the processing method; immediate catching is appropriate.
  2. Telling an external system that an unresolved issue has occurred and that it should handle the issue according to the exception semantics.

Understanding exception semantics

I should clarify here my definition of exception semantics. In my view, classes of objects should be designed according to their real-world equivalents. A fruit or a person can be designed easily as a Java object class. Exception design is different: while it is clear what a fruit or a person is in the real world, the same cannot be said of an exception. Actually, from the two exception categories above, only the first one exists in the real world. Exceptions in the second category model what can go wrong during system execution, and therefore do not exist outside the system. Immediate catching is thus appropriate only for exceptions in the first category.

My design proposal is based on the idea that exceptions should be designed according to their purpose. Exceptions that are internal to the system and self-regulatory are meant to help the system react in the case of unexpected conditions. The purpose of these exceptions is therefore not to model the issue at hand, but to give an indication of what kind of action the system must take.

1 2 3 4 Page 2
Page 2 of 4