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

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:

1. Catching and handling the exception, so the application continues running.
2. 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.