- Exception Handling Strategies
- Exception Handling Strategy - Overview
- Exception Handling Requirements
- Application Survival
- Notifying Relevant Parties
- Error Diagnostics and Reproduction
- Separation of Abstraction Layers
- More Readable and Maintainable Code
- Error Location and Context
- Error Causes, Types and Reactions
- Strategy Elements
- Error Detection
- Error Information Gathering
- Throwing Exceptions
- Propagating Exceptions
- Catching Exceptions
- An Exception Handling Strategy Template
- An Exception Class Template
- Throwing the AppException
- Propagating the AppException
- The ErrorInfo List
- Catching the AppException
- Avoid Exception Hierarchies
Error Information Gathering
Error information gathering means gathering the information needed to react to, and diagnose the error. The needed information is typically divided into two categories:
- Error Cause
- Error Location
Application end users, operators, administrators and developers typically need information about what caused the error. They need that to determine if and how to respond to the error, and whether the error is severe or not.
If the error is severe and e.g. need some debugging and bug fixing by the developers, then the developers also need to know the location of the error. Knowing the location of the error is essential to know where to start looking for the cause of the error. For instance, even if the error description said something like "Parameter XYZ was null, and it should be non-null", you still need to determine why that parameter was all of a sudden null. That is what I mean by the underlying cause.
Error cause and location information often includes:
|Cause||Technical error description||Developers, Operators / Administrators|
|Cause||End user error description||End Users|
|Cause||Relevant input / parameter / variable data||End Users, Developers, Operators / Administrators|
|Cause||Relevant system data in singletons, configurations, databases etc.||End Users, Developers, Operators / Administrators|
|Cause||Relevant external conditions
(is system XYZ up?).
|End Users, Developers, Operators / Administrators|
(included in exception)
|Location||Unique Error ID||Developers, Operators / Administrators|
Exactly what information you need to collect depends on your application, and what error that occurred. Some errors may need information about configuration setttings, or information fetched from database etc. Others may only need a simple error message - because the error is very simple, and easy to diagnose.
Additionally, what information to collect depends on what parties need to know about the error. If only the end user should be notified, you may not need to collect information about configuration settings etc.