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

• End Users
• Computerized Clients of Services
• Application Operators
• Application Administrators
• Application Developers
• Application Owners

When an exception occurs in your application the interested parties should be notified about it. The most typical interested parties are:

• The application end user, if any.
• The application operators.
• The application administrators.
• The application developers.
• The application owner, if external from your organization.

Each of these parties should receive different information. Additionally each party is also typically notified using different notification mechanisms. Here is a diagram showing an overview of notification:

Notifying relevant parties when an exception occurs.

I'll explore each of these categories of relevant parties in the sections below.

End Users

An end user should be notified that the requested operation cannot be completed, but the user should probably not see a stack trace, or other internal details about the exception. Such information can actually contain information that can be used to hack into your application. At most the end user should see an error description and perhaps a unique error code, in case the user wants further details about the error from the organization operating the application.

Application end users are typically notified about exceptions via the application user interface, whether that user interface is a command line, a desktop GUI or a browser GUI.

Computerized Clients of Services

Not all applications have human end users. Services that are intended for computer-to-computer communication typically do not have a user interface. In such cases the calling computer (the client) should be treated as the user. In other words, in case an exception occurs in the service, the client should be notified of the error. Yet again, it may not be a good idea to present the client with stack traces or other internal details except a unique error code and an error message.

Application Operators

The application operators are the people who monitor the application to make sure it is functioning correctly. In case of errors that the application cannot handle itself, the operators are typically also responsible for getting the application back in operational state.

By �responsible� I don't necessarily mean that they have to do it themselves. They just have to make sure that the right people are mobilized depending on the nature of the error.

Application operators should also be notified of errors in the application. Of course operators should only be notified of errors that need their attention. An exception thrown because the user types in something invalid are often not necessary to forward to the application operators.

Application operators are typically notified via the application log.

Application Administrators

The application administrators are the people who administer the computer the application is installed on. Hence, the application administrators are typically responsible for installing the application on these computers too. Application administrators are also responsible for starting and stopping applications.

Application administrators should be notified if an error in an application is caused by something related to the computer or application administration. For instance, a configuration file could be missing or contain invalid settings. The administrators should then check if the configuration file is present, and that it contains valid settings. Or, an application could be reporting that an external system needed by the application does not respond. The administrators should then check the state of this external system.

Application administrators are typically notified of errors via the application log, or via the application operators.

In some organizations the application operator and application administrator responsibilities are carried out by the same people. In other organizations these responsibilities are divided between two different groups of people.

Application Developers

The application developers are the software developers who have developed or are maintaining the application.

Application developers should be notified of errors that may be caused by bugs in the software. Actually, the developers are often notified of any error that operators and administrators cannot resolve.

Application developers are typically notified via the operators who monitor the application log.

Application Owners

If the application is being hosted for an external customer, that customer may also want to be notified of errors. Exactly what errors they are interested in depends on the application and the customer, but if an error causes their application to be unavailable you can be sure that they are very interested in knowing that.