- 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
When an exception is thrown in an application, the application should be able to survive this exception, and continue to process events, requests, files etc. Application survival is divided into two sub-requirements:
- Catching and handling the exception, so the application continues running.
- Opened resources are closed correctly.
Both of these requirements are described in more detail below:
Catching and Handling the Exception
When an exception occurs, the application must catch the exception somewhere, handle it, and continues as if the exception had never occurred (if possible).
If the error causing the exception is so severe that the application cannot continue executing, e.g. a required configuration file is missing, the application must shut down gracefully.
Closing Resources Correctly
Open resources which require explicit closing or freeing after use, should be closed or freed correctly, even if an exception is thrown while using them.
Typical examples of such resources are thread locks, streams, network connections (sockets / channels), database connections, JMS connections etc. In applications using Java NIO some memory buffers must be freed explicitly. In SWT applications SWT GUI components need explicit disposing after use.
You should of course not close each and every resource in the application when an exception is thrown. Only resources opened to serve the request that fails should be closed when an exception occurs. Connections in connection pools and other long term cached resources should not be affected by the exception. Of course resources obtained from pools should be returned correctly to the pool even if an exception occurs, but the pool itself should not be closed.
Only if the application is shutting down completely should all open resources be closed.