- 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
Notifying Relevant Parties
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.
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.
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.
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.
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.
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.