I was writing a new library in C++ and I needed some kind of chained exceptions facility to better handle the errors generated by my code. Chained exceptions are useful because they allow you to have a sort of stack dump at the moment when the error occurred, and some implementations may also include the state of the functions listed in the stack dump.
A chained exception is created when a function doesn't let an uncaught exception go but catches it and wraps it in a new exception (the chained exception) that is thrown in place of the original one. The new chained exception also contains some information related to the place where the catch & throw happened, and sometimes other information that may be useful to the programmer.
The first catch statement that doesn't panic and is able to deal with the abnormal condition can analyze the content of the chained exception and determine the chain of functions that generated it; as noted before, it's almost a stack dump of the moment when the error occurred.
The Problem
The problem is that the exception being caught is not the original one: if an exception is not processed immediately, then it is lost, or it can be caught only by using special techniques (like catching the chained exception and then analyzing its content).
For instance, have a look at Figure 1: It represents the code of four functions that are used to decode an image file. There is a codec manager, which calls the jpeg decoder which in turn calls the huffman decoder.
Figure 1: Four functions with catch and throw macros.
The code doesn't use the chained exceptions; all the functions have a catch and throw macro, which catches the uncaught exceptions and re-throws them without modifications.
The huffman decoder sooner or later has to read some bytes from the input file, but something goes wrong because the file reader detects an end of file and throws an EOF exception. Then the following events happen:
- The catch and throw macro at the end of the file reader function detects the uncaught EOF, but it doesn't know what to do with it, so it simply rethrows it
- The huffman decoder and also the jpeg decoder are afraid of the EOF exception, so they simply rethrow it through the catch and throw macro
- Finally, the codec manager catches the EOF and decides that the input file is corrupted; it may just return an error, or decide to keep the part of the image already decoded.
As you can see, the EOF exception is not processed immediately, but only when it reaches the codec manager; all the other functions don't know how to deal with it.
If the code was using chained exceptions, it could not simply try to catch the EOF in the codec manager, because at that point the EOF was wrapped deep inside a chain of chained exceptions.
But are the macros only catching and throwing the exceptions? Do they just caress the exceptions before they are thrown into the darkness? Perhaps they also keep track of the place where the catch and throw happened, and perhaps they also remember some other information, so a catch statement can analyze the stack dump of the moment when the original error happened, just like the chained exceptions do.
