1. Exception Handling Strategies
2. Exception Handling Strategy - Overview
3. Exception Handling Requirements
4. Application Survival
5. Notifying Relevant Parties
6. Error Diagnostics and Reproduction
7. Separation of Abstraction Layers
8. More Readable and Maintainable Code
9. Error Location and Context
10. Error Causes, Types and Reactions
11. Strategy Elements
12. Error Detection
13. Error Information Gathering
14. Throwing Exceptions
15. Propagating Exceptions
16. Catching Exceptions
17. An Exception Handling Strategy Template
18. An Exception Class Template
19. Throwing the AppException
20. Propagating the AppException
21. The ErrorInfo List
22. Catching the AppException
23. Avoid Exception Hierarchies

• A Hierarchy is an Insufficient Categorization of Exceptions
• Hierarchies Clutters Exception Propagation

You may have noticed that the exception handling template shown earlier in this tutorial, only uses a single exception class. There are no exception hierarchies. The reason I have avoided exception hierarchies, is because they don't really add much value to the template. Allow me to explain why I think so.

If you are not familiar with exception hierarchies, I have explained how they work in Java, in the text Exception Hierarchies

A Hierarchy is an Insufficient Categorization of Exceptions

Exception hierarchies are basically a way of categorizing exceptions. The standard Java API's typically categorize exceptions after what caused the exception. Like IOException,

However, as you have seen in this tutorial, there are several parameters that are needed to determine how to handle an exception, and not just its original cause. Thus, the categorization a hierarchy provides is insufficient to carry all the necessary information needed to handle an exception.

Proper exception handling requires both knowledge about the type of error (internal, client, service), the context in which the exception occurred, the severity etc. All that cannot be fitted into a single categorization.

Since not all information needed in an exception can be contained in an exception hierarchy, it is easier to just leave out the hierarchy completely, and just use a single exception class.

Hierarchies Clutters Exception Propagation

Leaving out the exception hierarchy also makes exception propagation easier. If a method can throw 3 different exceptions, which all extend the same superclass, should your method declare each of the 3 different exception subclasses, or just the exception superclass?

When there is only a single exception used in your application, you will always just propagate that up the call stack, if your method propagates the exception rather than handling it locally.