• Next chapter
• Previous chapter
• Table of contents

Chapter 8: Exceptions

We're always interested in getting feedback. E-mail us if you like this guide, if you think that important material is omitted, if you encounter errors in the code examples or in the documentation, if you find any typos, or generally just if you feel like e-mailing. Send your email to Frank Brokken.

Please state the document version you're referring to, as found in the title (in this document: 5.2.0a) and please state the paragraph you're referring to.

All mail received is seriously considered, and new (sub)releases of the Annotations will normally reflect your suggestions for improvements. Except for the incidental case I will not otherwise acknowledge the receipt of suggestions for improvements. Please don't misinterpret this for lack of appreciation.

In C there are several ways to have a program react to situations which break the normal unhampered flow of the program:

• The function may notice the abnormality and issue a message. This is probably the least disastrous reaction a program may show.
• The function in which the abnormality is observed may decide to stop its intended task, returning an error code to its caller. This is a great example of postponing decisions: now the calling function is faced with a problem. Of course the calling function may act similarly, by passing the error code up to its caller.
• The function may decide that things are going out of hand, and may call exit() to terminate the program completely. A tough way to handle a problem....
• The function may use a combination of the functions setjmp() and longjmp() to enforce non-local exits. This mechanism implements a kind of goto jump, allowing the program to continue at an outer level, skipping the intermediate levels which would have to be visited if a series of returns from nested functions would have been used.

In C++ the alternative to using setjmp() and longjmp() are exceptions. Exceptions implement a mechanism by which a controlled non-local exit is realized within the context of a C++ program, without the disadvantages of longjmp() and setjmp().

Exceptions are the proper way to bail out of a situation which cannot be handled easily by a function itself, but which are not disastrous enough for the program to terminate completely. Also, exceptions provide a flexible layer of flow control between the short-range return and the crude exit().

In this chapter the use of exceptions and their syntax will be discussed. First an example of the different impacts exceptions and setjmp() and longjmp() have on the program will be given. Then the discussion will dig into the formalities of using exceptions.

8.1: Using exceptions: syntax elements

• try: The try-block surrounds statements in which exceptions may be generated (the parlance is for exceptions to be thrown). Example:

      try
      {
          // statements in which exceptions may be thrown
      }
  

• throw: followed by an expression of a certain type, throws the value of the expression as an exception. The throw statement must be executed somewhere within the try-block: either directly or from within a function called directly or indirectly from the try-block. Example:

      throw "This generates a char * exception";
  

• catch: Immediately following the try-block, the catch-block receives the thrown exceptions. Example of a catch-block receiving char * exceptions:

      catch (char *message)
      {
          // statements in which the thrown char * exceptions are handled
      }
  

8.2: An example using exceptions

That's about it. The function Outer::fun() terminates, and the destructor of the Inner object is called. Then the program terminates and the destructor of the Outer object is called. Here is the basic program:

    #include <iostream>
    using namespace std;
    
    class Inner
    {
        public:
            Inner();
            ~Inner();
            void fun();    
    };
    
    class Outer
    {
        public:
            Outer();
            ~Outer();
            void fun();
    };
    
    Inner::Inner()
    {
        cout << "Inner constructor\n";
    }    
    
    Inner::~Inner()
    {
        cout << "Inner destructor\n";
    }    
    
    void Inner::fun()
    {
        cout << "Inner fun\n";
    }    
    
    Outer::Outer()
    {
        cout << "Outer constructor\n";
    }    
    
    Outer::~Outer()
    {
        cout << "Outer destructor\n";
    }    
    
    void Outer::fun()
    {
        Inner in;
    
        cout << "Outer fun\n";
        in.fun();
    }    
    
    int main()
    {
        Outer out;
    
        out.fun();
    }

    /*
        Generated output:
    Outer constructor
    Inner constructor
    Outer fun
    Inner fun
    Inner destructor
    Outer destructor
    */

Now let's focus our attention on two variants, in which we simulate a non-fatal disastrous event to take place in the Inner::fun() function, which is supposedly handled somewhere at the end of the function main(). We'll consider two variants. The first variant will try to handle this situation using setjmp() and longjmp(); the second variant will try to handle this situation using C++'s exception mechanism.

8.2.1: No exceptions: `setjmp()' and `longjmp()'

To complete the simulation, the return value of the program is zero only if the program is able to return from the function Outer::fun() normally. However, as we know, this won't happen: Inner:fun() calls longjmp(), returning to the setjmp() function, which (at this time) will not return a zero return value. Hence, after calling Inner::fun() from Outer::fun() the program proceeds beyond the if-statement in the main() function, and the program terminates with the return value 1. Now try to follow these steps by studying the following program source, modified after the basic program given in section 8.2:

    #include <iostream>
    #include <setjmp.h>
    #include <cstdlib>

    using namespace std;
    
    class Inner
    {
        public:
            Inner();
            ~Inner();
            void fun();
    };
    
    class Outer
    {
        public:
            Outer();
            ~Outer();
            void fun();
    };
    
    jmp_buf
        jmpBuf;
    
    Inner::Inner()
    {
        cout << "Inner constructor\n";
    }    
    
    void Inner::fun()
    {
        cout << "Inner fun()\n";
        longjmp(jmpBuf, 0);
    }    
    
    Inner::~Inner()
    {
        cout << "Inner destructor\n";
    }    
    
    Outer::Outer()
    {
        cout << "Outer constructor\n";
    }    
    
    Outer::~Outer()
    {
        cout << "Outer destructor\n";
    }    
    
    void Outer::fun()
    {
        Inner in;

        cout << "Outer fun\n";
        in.fun();
    }    
    
    int main()
    {
        Outer out;
    
        if (!setjmp(jmpBuf))
        {
            out.fun();
            return 0;
        }
        return 1;
    }
    /*
        Generated output:
    Outer constructor
    Inner constructor
    Outer fun
    Inner fun()
    Outer destructor
    */

Since this example shows that the destructors of objects can easily be skipped when longjmp() and setjmp() are used, it's probably best to avoid these function completely in C++ programs.

8.2.2: Exceptions: the preferred alternative

    #include <iostream>
    using namespace std;
    
    class Inner
    {
        public:
            Inner();
            ~Inner();
            void fun();
    };
    
    class Outer
    {
        public:
            Outer();
            ~Outer();
            void fun();
    };
    
    Inner::Inner()
    {
        cout << "Inner constructor\n";
    }    
    
    Inner::~Inner()
    {
        cout << "Inner destructor\n";
    }    
    
    void Inner::fun()
    {
        cout << "Inner fun\n";
        throw 1;
        cout << "This statement is not executed\n";
    }    
    
    Outer::Outer()
    {
        cout << "Outer constructor\n";
    }    
    
    Outer::~Outer()
    {
        cout << "Outer destructor\n";
    }    
    
    void Outer::fun()
    {
        Inner in;

        cout << "Outer fun\n";
        in.fun();
    }    
    
    
    int main()
    {
        Outer out;

        try
        {
            out.fun();
        }
        catch (...)
        {}
    }
    /*
        Generated output:
    Outer constructor
    Inner constructor
    Outer fun
    Inner fun
    Inner destructor
    Outer destructor
    */

So, comparably to the example given in section 8.2.1, the execution of function Inner::fun() terminates, albeit with an exception, rather than a longjmp(). The exception is caught in main(), and the program terminates. When the output from the current program is inspected, we notice that the destructor of the Inner object, created in Outer::fun() is now correctly called. Also notice that the execution of the function Inner::fun() really terminates at the throw statement: the insertion of the text into cout, just beyond the throw statement, doesn't take place.

Hopefully we now have raised your appetite for exceptions by showing that

• Exceptions provide a means to break out of the normal flow control without having to use a cascade of return-statements, and without the need to terminate the program.
• Exceptions do not disrupt the activation of destructors, and are therefore strongly preferred over the use of setjmp() and longjmp().

8.3: Throwing exceptions

    throw "Hello world";        // throws a char *
    throw 18;                   // throws an int
    throw string("hello");      // throws a string

The next example illustrates this point. Within the function Object::fun() a local Object toThrow is created, which is thereupon thrown as an exception. The exception is caught outside of Object::fun(), in main(). At this point the thrown object doesn't actually exist anymore, Let's first take a look at the sourcetext:

    #include <iostream>
    using namespace std;
    
    class Object
    {
        string
            d_name;

        public:
            Object(string name)
            :
                d_name(name)
            {
                cout << "Object constructor of " << d_name << "\n";
            }    
            Object(Object const &other)
            :
                d_name(other.d_name + " (copy)")
            {
                cout << "Copy constructor for " << d_name << "\n";
            }    
            ~Object()
            {
                cout << "Object destructor of " << d_name << "\n";
            }    
            void fun()
            {
                Object toThrow("'local object'");
            
                cout << "Object fun() of " << d_name << "\n";
                throw toThrow;
            }    
            void hello()
            {
                cout << "Hello by " << d_name << "\n";
            }        
    };
    
    int main()
    {
        Object out("'main object'");
    
        try
        {
            out.fun();
        }
        catch (Object o)
        {
            cout << "Caught exception\n";
            o.hello();
        }
    }
    /*
        Generated output:
Object constructor of 'main object'
Object constructor of 'local object'
Object fun() of 'main object'
Copy constructor for 'local object' (copy)
Object destructor of 'local object'
Copy constructor for 'local object' (copy) (copy)
Caught exception
Hello by 'local object' (copy) (copy)
Object destructor of 'local object' (copy) (copy)
Object destructor of 'local object' (copy)
Object destructor of 'main object'
    */

    Object constructor of 'main object'
    Object constructor of 'local object'
    Object fun() of 'main object'

    Copy constructor for 'local object' (copy)

    Object destructor of 'local object'
    Copy constructor for 'local object' (copy) (copy)

    Caught exception

    Hello by 'local object' (copy) (copy)

    Object destructor of 'local object' (copy) (copy)
    Object destructor of 'local object' (copy)
    Object destructor of 'main object'

If the catcher would have been implemented so as to receive a reference to an object (which you could do by using `catch (Object &o)'), then the double copy would have been avoided. In that case the output of the program would have been:

Object constructor of 'main object'
Object constructor of 'local object'
Object fun() of 'main object'
Copy constructor for 'local object' (copy)
Object destructor of 'local object'
Caught exception
Hello by 'local object' (copy)
Object destructor of 'local object' (copy)
Object destructor of 'main object'

Of course, it's a bad idea to throw a pointer to a locally defined object: the pointer is thrown, but the object to which the pointer refers dies once the exception is thrown, and the catcher receives a wild pointer. Bad news....

Summarizing, local objects are thrown as copied objects, pointers to local objects should not be thrown. However, it is possible to throw pointers or references to dynamically generated objects. In this case one must take care that the generated object is properly deleted when the generated exception is caught, to prevent a memory leak.

Exceptions are thrown in situations where a function can't continue its normal task anymore, although the program is still able to continue. Imagine a program which is an interactive calculator. The program continuously requests expressions, which are then evaluated. In this case the parsing of the expression may show syntactical errors; and the evaluation of the expression may result in expressions which can't be evaluated, e.g., because of the expression resulting in a division by zero. Also, the calculator might allow the use of variables, and the user might refer to non-existing variables: plenty of reasons for exceptions to be thrown, but no overwhelming reason to terminate the program. In the program, the following code may be used, all throwing exceptions:

    if (!parse(expressionBuffer))           // parsing failed 
        throw "Syntax error in expression";

    if (!lookup(variableName))              // variable not found
        throw "Variable not defined";

    if (divisionByZero())                   // unable to do division 
        throw "Division by zero is not defined";

would allow us to throw more specific messages, like

    if (!lookup(variableName))
        throw formatMessage("Variable '%s' not defined", variableName);

8.3.1: The empty `throw' statement

In this situation an intermediate exception handler is called for. A thrown exception is first inspected at the middle level. If possible it's processed there. If it is not possible to process the exception at the middle level, it is passed on, unaltered, to a more superficial level, where the really tough exceptions are handled.

By placing an empty throw statement in the code handling an exception the received exception is passed on to the next level that might be able to process that particular type of exception.

In our server-client situation a function

could be designed to do so. The received message is inspected. If it's a simple message it's processed, otherwise the exception is passed on to an outer level. The implementation of initialExceptionHandler() shows the empty throw statement:

    void initialExceptionHandler(char *exception)
    {
        if (!plainMessage(exception))
            throw;

        handleTheMessage(exception);
    }

Does this sound intriguing? Then try to follow the next example, which jumps slightly ahead to the topics covered in chapter 14. The next example may be skipped, though, without loss of continuity.

We can now state that a basic exception handling class can be constructed from which specific exceptions are derived. Suppose we have a class Exception, containing a member function ExceptionType Exception::severity(). This member function tells us (little wonder!) the severity of a thrown exception. It might be Message, Warning, Mistake, Error or Fatal. Furthermore, depending on the severity, a thrown exception may contain less or more information, somehow processed by a function process(). In addition to this, all exceptions have a plain-text producing member function, e.g., toString(), telling us a bit more about the nature of the generated exception. Using polymorphism, process() can be made to behave differently, depending on the nature of a thrown exception, when called through a basic Exception pointer or reference.

In this case, a program may throw all these five types of exceptions. Let's assume that the Message and Warning exceptions are processable by our initialExceptionHandler(). Then its code would become:

    void initialExceptionHandler(Exception const *e)
    {
        cout << e->toString() << endl;  // show the plain-text information

        if 
        (
            e->severity() != ExceptionWarning 
            &&
            e->severity() != ExceptionMessage
        )
            throw;                      // Pass on other types of Exceptions

        e->process();               // Process a message or a warning
        delete e;
    }

    throw new Message(<arguments>);
    throw new Warning(<arguments>);
    throw new Mistake(<arguments>);
    throw new Error(<arguments>);
    throw new Fatal(<arguments>); 

8.4: The try block

The keyword try is followed by a set of curly braces, which acts like a standard C++ compound statement: multiple statements and variable definitions may be placed here.

It is possible (and very common) to create levels in which exceptions may be thrown. For example, code within the main() function is surrounded by a try-block, forming an outer level in which exceptions can be handled. Within the try-block in main(), functions are called which may also contain try-blocks, forming the next level in which exceptions may be placed. As we have seen (in section 8.3.1), exceptions thrown in inner level try-blocks may or may not be processed at that level. By placing an empty throw in an exception handler, the thrown exception is passed on to the next (outer) level.

If an exception is thrown outside of any try-block, then the default way to handle (uncaught) exceptions is used, which is normally to abort the program. Try to compile and run the following tiny program, and see what happens:

    int main()
    {
        throw "hello";
    }

8.5: Catching exceptions

    catch (char const *message)
    {
        // code to handle the message
    }

Generally, close attention must be paid to the nature of the parameter of the exception handler, to make sure that exception: dynamically generated dynamically generated exceptions are deleted once the handler has processed them. Of course, when an exception is passed on to an outer level exception handler, the received exception should not be deleted by the inner level handler.

Different kinds of exceptions may be thrown: char *s, ints, pointers or references to objects, etc.: all these different types may be used in throwing and catching exceptions. So, various types of exceptions may come out of a try-block. In order to catch all expressions that may emerge from a try-block, multiple exception handlers (i.e., catch-blocks) may follow the try-block.

The order in which the exception handlers are placed is important. When an exception is thrown, the first exception handler matching the type of the thrown exception is used and remaining exception handlers are ignored. So only one exception handler following a try-block will be executed. Consequently, exception handlers should be placed from the ones having the most specific parameters to the ones having more general parameters. For example, if exception handlers are defined for char *s and void *s (i.e., any old pointer) then the exception handler for the former exception type should be placed before the exception handler for the latter type:

    try
    {
        // throws all kinds of pointers
    }
    catch (char const *message)
    {
        // processing thrown char pointers
    }
    catch (void *whatever)
    {
        // processing all other thrown pointers
    }

    try
    {
        // code throws only Exception pointers
    }
    catch (Exception *e)
    {
        e->process();
        delete e;    
    }

When the code of an exception handler that is placed beyond a try-block has been processed, the execution of the program continues beyond the last exception handler following that try-block (unless the handler uses return, throw or exit() to leave the function prematurely). Therefore, we distinguish the following cases:

• If no exception was thrown within the try-block no exception handler is activated, and the execution continues from the last statement in the try-block to the first statement beyond the last catch-block.
• If an exception was thrown within the try-block but neither the current level nor an other level contains an appropriate exception handler, the program's default exception handler is called, usually aborting the program.
• If an exception was thrown within the try-block and an appropriate exception handler is available, then that the code of that exception handler is executed. Following the execution of the code of the exception handler, the execution of the program continues at the first statement beyond the last catch-block.

The actual computation or construction of the exception may be performed in various degrees of sophistication. Several possibilities are to use a plain new operator; to use static member functions of a class; to return a pointer to an object; or to use objects of classes derived from a class, possibly involving polymorphism.

8.5.1: The default catcher

An intermediate kind of exception handling may be implemented using the default exception handler, which should (due to the hierarchical nature of exception catchers, discussed in section 8.5) be placed beyond all other, more specific exception handlers. In this case, the current level of exception handling may do some processing by default, but will then, using the the empty throw statement (see section 8.3.1), pass the thrown exception on to an outer level. Here is an example showing the use of a default exception handler:

    #include <iostream>
    using namespace std;

    int main()
    {
        try
        {
            try
            {
                throw 12.25;    // no specific handler for doubles
            }
            catch (char const *message)
            {
                cout << "Inner level: caught char const *\n";
            }
            catch (int value)
            {
                cout << "Inner level: caught int\n";
            }
            catch (...)
            {
                cout << "Inner level: generic handling of exceptions\n";
                throw;
            } 
        }
        catch(double d)
        {
            cout << "Outer level still knows the double: " << d << endl;
        }
    }
    /*
        Generated output:
    Inner level: generic handling of exceptions
    Outer level still knows the double: 12.25
    */

8.6: Declaring exception throwers

These external functions may of course throw exceptions. The declaration of such functions may contain a function throw list, in which the types of the exceptions that can be thrown by the function are specified. For example, a function that may throw `char *' and `int' exceptions can be declared as

A function throw list may appear after the function header (including a possible const specifier), and, noting that the throw list may be empty, it has the following generic form: throw([type1 [, type2, type3, ...]])

If a function doesn't throw exceptions an empty function throw list may be used. E.g.,

In this case the function definition must contain the empty function throw list too.

A function for which a function throw list is specified may not throw other types of exceptions. A run-time error occurs if it tries to throw other types of exceptions than mentioned in the function throw list.

If a function throw list is specified in the declaration, it must also be given in the definition of the function. For example, using declaration and definition in the next example:

    #include <iostream>
    using namespace std;

    void charPintThrower() throw(char const *, int);    // declarations

    class Thrower
    {    
        public:
            void intThrower(int) const throw(int);  
    };

    void Thrower::intThrower(int x) const throw(int)    // definitions
    {
        if (x)
            throw x;
    }
    
    void charPintThrower() throw(char const *, int)
    {
        int x;

        cerr << "Enter an int: ";
        cin >> x;
    
        Thrower().intThrower(x);
        throw "this text is thrown if 0 was entered";
    }

    void runTimeError() throw(int)
    {
        throw 12.5;
    }
    
    int main()
    {
        try
        {
             charPintThrower();
        }    
        catch (char const *message)
        {
            cerr << "Text exception: " << message << endl;
        }
        catch (int value)
        {
            cerr << "Int exception: " << value << endl;
        }
        try
        {
            cerr << "Up to the run-time error\n";
            runTimeError();
        }
        catch(...)
        {
            cerr << "not reached\n";
        }
    }

If the function throw list is not used, the function may either throw exceptions (of any kind) or not throw exceptions at all. Without a function throw list the responsibility of providing the correct handlers is in the hands of the designer of the program.

8.7: Iostreams and exceptions

• iostate exceptions(): this member returns the state flags for which the stream will throw exceptions,
• void exceptions(iostate state): this member will throw an exception when state state is observed.

Exceptions should be used for truly exceptional situations. Therefore, we think it is questionable to have stream objects throw exceptions for rather standard situations like EOF. Considering exceptions when input errors occur might be defensible, for example when input errors should not occur and imply a corrupted file. But here we think aborting the program with an appropriate error message usually is a more appropriate line of action. In any case, here is an example showing the use of exceptions in an interactive program, expecting numbers:

    #include <iostream>
    using namespace::std;

    int main()
    {
        cin.exceptions(ios::failbit);

        while (true)
        {
            try
            {
                cout << "enter a number: ";

                int value;

                cin >> value;
                cout << "you entered " << value << endl;
            }
            catch (ios::failure const &problem)
            {
                cout << problem.what() << endl;
                cin.clear();
                string s;
                getline(cin, s);
            }
        }
    }

• Next chapter
• Previous chapter
• Table of contents