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

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:

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.