Exception Hierarchy

There should be a standard hierarchy of Exceptions based on how users are expected to handle them, independent of the classes and packages that happen to throw them.

All Exceptions should implement one of two interfaces:

SystemException?:: system level failure -- running out of memory, database connections, etc...
BusinessException?:: business rule violated -- validation rules, security constraints, etc...

Using such a hierarchy would make it easier to understand how to handle an Exception.

: A BusinessException? must always either be handled by the business process itself (e.g. send notification of invalid contract) or by a user. (For example, the user could re-enter zip code.)
: A SystemException?, on the other hand, cannot be corrected by the end-user.

There advantage is that it is more clear how to handle an exception: If it is a BusinessException?, then some person probably needs to be notified. If it is a SystemException? the end-user probably can't do anything about it so you need to think of some other strategy.

The failure of the Java language (and in others I imagine) is that Exceptions are tied closely to classes and packages.

(ShamelessPlug?: In CommonLisp, exceptions are almost entirely decoupled from both classes and packages.)

[Original text by DaveTauzell (10/12/2001). Edited heavily by JeffGrigg on 10/15/2001.]

The Java language currently contains java.lang.Error and java.lang.Exception, which are similar in some respects to what is described above.

(Perhaps we need a better separation between "business" and "technical" exceptions within java.lang.Exception.)

Why not just create your own Business Exception class, and derive all your other "business" exceptions from that? Why should such a thing be defined by the Java language/runtime (or whatever other programming language you are using)?

Because you still have to deal with lots of Java exceptions under java.lang.Exception, and they're not in a very useful hierarchy, judging from the perspective of the application I happen to be writing.

(Personally, I think this page is wishful thinking, as there really isn't any way a framework developer can tell, in advance, how their users will view exceptions on the business -vs- system boundary. And the line will move from time to time, even within a single application system. -- JeffGrigg)

Java exception hierarchy:

http://www.ebone.at/books/programmers/sonstiges/oreillybookself/java/langref/ch09_04.htm

Also: Java has a MessyExceptionHierarchy.

The problem is that one person's business rule is another person's system rule. E.g. my XML parsing library throws an exception because the XML syntax is invalid. From my point of view, a business rule was violated (invalid input). You might see this quite differently, especially if the XML file wasn't directly provided by the user but is some configuration file of which the user knows little.

I agree. The distinction between "business" and "system" doesn't really capture the different kinds of errors. I see three categories:

Programming errors -- violations of preconditions, postconditions and invariants. Continuing reliable execution in the face of these errors is complex and expensive: e.g. voting algorithms, consensus algorithms, running multiple copies of the same algorithm all written by different teams, hardware protection, etc. For many systems it is adequate to just restart the failed program.
Environmental errors -- errors caused events beyond the control of the program, such as disks filling up, network connections failing, files being malformed, etc. These should be checked by reliable code, and are easier to recover from.
Errors in the runtime system -- the implementation of the language itself has failed in some way and can no longer be trusted. E.g. the program can no longer be sure that contracts are being implemented correctly.

Do you think this it would be a good idea to implement this as a project or enterprise standard within a development organization? --DaveTauzell

CategoryException