C++ Exception Model

In the C++ object-oriented model of handling exceptions, an application can only catch exceptions that are explicitly thrown by that application. This implies that exceptions caused by the underlying system will either make the application undefined, or will result in a crash. Generally, the following advantages are attributed to this (synchronous) mechanism.

Pay as needed. This refers to the fact that, every exception that an application intends to catch must be thrown by the application. Since exceptions caused by the underlying system are to be caught, one generally pays for everything. Hence, this is a rather useless feature for developing large and complex applications. However, system programs are generally smaller and deal with a few specific exceptions. Even in the latter case, a predetermined set of well-known exceptions could be supported, which is not possible with the C++ rudimentary model.

Overhead. Since there is a minimal overhead involved for catching exceptions that may be caused by external events, this is a true statement. Again, it is only worth in the context of system programs, which demand the most efficiency. For reasons of efficiency, in most cases such programs are written in C, and not C++. Furthermore, one ignores the fact that the creation of exception objects and throwing them arround is quite costly.

Termination. The C++ model is known as Termination as opposed to Resumption. This of course is a contradiction. One does not simply catch an exception only to report diagnostics, and terminate. This is hardly worth referring to as “handling an exception”. The C++ exception model is effectively a complicated logging mechanism.

Exception.pdf illustrates the advantages of Z++ model of exception handling for developing large and complex applications.