The purpose of structured exception handling is to eliminate the type of control coupling that occurs when error codes are passed up through calling methods by means of a return value or a parameter until a method is reached that can handle the error. When errors are handled in this way, each method in the call stack has to implement code to check the error code and decide what to do. The decision is generally to suspend whatever the routine is doing and pass an error code up to the next level until a level is reached that handles the error. Structured error handling eliminates the need for all this error handling code between the level where the error occurred and where it is handled.
Programmers that are unaware of the intent of structured error handling will often write code to catch exceptions within each routine, convert the exceptions into error codes, and then pass the error codes up to the calling routine through a return value or parameter. Handling exceptions like that is kind of like using goto statements when you could be using if-then-else or some other structured programming construct. Don’t convert exceptions to error codes unless some interface requires it.
The Microsoft Exception Management Application Block
Many people recommend using the Microsoft Exception Management Application Block (EMAB). I don’t. In all fairness, though, when I was evaluating EMAB, I was evaluating it for use in a client-side application. The EMAB is best suited for server-side applications when there is a need to configure the exception handling behavior of the application after it has been deployed. Since EMAB has a fairly steep learning curve (in comparison with other components) I don’t recommend it for any other case.
Experiments in Exception Handling
Write a some short programs with exceptions and debug output to illustrate what happens to exceptions that occur in certain places.
Exceptions and remoting.
Exceptions have to be serialized and deserialized when the cross a remote interface.