(^42) 97 Things Every Programmer Should Know
Distinguish Business Exceptions from Technical ...........
Dan Bergh Johnsson
THERE ARE BASiCALLY TWO REASONS that things go wrong at runtime:
technical problems that prevent us from using the application and business
logic that prevents us from misusing the application. Most modern languages,
such as LISP, Java, Smalltalk, and C#, use exceptions to signal both these situa-
tions. However, the two situations are so different that they should be carefully
held apart. It is a potential source of confusion to represent them both using
the same exception hierarchy, not to mention the same exception class.
An unresolvable technical problem can occur when there is a programming
error. For example, if you try to access element 83 from an array of size 17,
then the program is clearly off track, and some exception should result. The
subtler version is calling some library code with inappropriate arguments,
causing the same situation on the inside of the library.
It would be a mistake to attempt to resolve these situations you caused your-
self. Instead, we let the exception bubble up to the highest architectural level
and let some general exception-handling mechanism do what it can to ensure
that the system is in a safe state, such as rolling back a transaction, logging and
alerting administration, and reporting back (politely) to the user.
A variant of this situation is when you are in the “library situation” and a caller
has broken the contract of your method, e.g., passing a totally bizarre argu-
ment or not having a dependent object set up properly. This is on a par with
accessing the 83rd element from 17: the caller should have checked; not doing
so is a programmer error on the client side. The proper response is to throw a
technical exception.