Lecture Notes for Advanced Programming II

10 February 2004 - Exceptions

Exceptions

• The Error Problem

• Exception Basics

• Exception Problems

• Basic Exception Mechanisms

  • The throw Statement

  • The catch Statement

  • The try Statement

• Exception Problems II

• Exception Mechanism Refinements

• Exception Problems III

• Further Exception Refinements

• Points to Remember

Errors

• What happens if there's an error in a constructor?

  // How can widget::widget() 
  // handle internal errors?
  
  widget w();  
  

• What happens if there's an error in an overloaded operator?

  // How can widget::operator + () 
  // handle internal errors?
  
  w1 = w1 + w2; 
  

The Error Pass-Along Problem

• The constructor or operator can

  • ignore the error.

    • But this is not always possible or advisable.

  • print an error message and die.

    • This is helpful, but not always useful.

  • try to handle the error.

    • Possible, but difficult because the context isn't known.

  • indicate an error some how.

    • Better, but how?

• This is the error pass-along problem.

Solving the Error Pass-Along Problem

• You can function return error values.

  status e = f();
  

  • Complicates normal functions.

  • Constructors can't return any values.

• You can pass error values through procedure parameters.

  int f(status & err) { ... }
  

  • Operators only have two parameters.

• You can use globals to pass error values.

  status err = error::none;
  f();
  if (err != error::none) { ... }
  

  • Not well structured; not thread safe.

Exceptions

• Exceptions provide an alternative mechanism for delivering error indications.

  • Exceptions can be used by any code, not just constructors and overloaded operators.

• Exceptions are not propagated along parameters, return values, or globals.

  • This is known as out-of-band communication.

  • This property makes them useful for constructors and operators.

• Uninterested code can chose to ignore exceptions.

  • But, alas, it's not that simple.

  • Uninterested code still needs to be exception safe.

Exception Basics

• Each instance of a called procedure has a stack frame.

  • The stack frame holds parameters, local variables, and other things related to the called procedure.

• The call stack contains the stack frames of all currently called procedures.

• When one one procedure calls another, the called procedure pushes its stack frame on the call stack.

• When the top procedure returns, it pops its call stack frame off the call stack.

Call Stack Example

• Consider

  int main () {   int f() {   int g() {
    f()             g()         if (b) g()
    }               }           }
  

• Initially main() is called, and main() calls f().
  

• f() then calls g().
  

• Eventually f() and g() return.
  

• main() returns and the program ends.

Exceptions and the Call Stack

• The top of the call stack can throw an exception.

  • This terminates the throwing procedure, popping it from the call stack.

• Each new call-stack top may catch the exception, or let it pass.

  • Catching the exception continues execution at the catching procedure.

  • Letting the exception pass terminates the procedure, popping it from the call stack.

    • The new call-stack top repeats the procedure.

• Popping the call stack because of exceptions is known as unwinding the call stack.

  • Popping the call stack is orderly: destructors are called for the class instances in the stack frame being popped.

• Completely unwinding the call stack terminates the program.

Exception Problems

• Exceptions are completely different from everything else.

  • Another new and different thing to learn, understand, and deal with.

  • New control flow, new scoping, new type-matching rules.

• Intervening procedures have no chance to clean up.

  f() {
    char * cp = new char [100];
    FILE * inf = open(fname, O_RDONLY);
    g()
    delete [] cp;
    close(inf);
    }
  

  • If g() throws an exception, f() terminates immediately.

• There is no such thing as uninterested code.

  • All code needs to be exception safe.

• Coordinated exceptions among independent modules requires work.

  • Which procedures throw what exceptions when?

Basic Exception Mechanisms

• C++ has three statements for dealing with exceptions.

  1. throw throws exceptions.

  2. catch catches exceptions.

  3. try delimits exception handling.

• Any code dealing with exceptions has to use one or more of these statements.

The throw Statement

• The throw statement launches (throws, raises, signals) an exception.

• throw expr throws the value expr as an exception.

  • Like return in syntax and semantics.

  • Control leaves the throwing procedure immediately after the throw is executed.

• expr can be a value of any type (except void).

• The throwing procedure ends at the throw.

• Examples

  throw 1;
  
  throw stack_trace("g()"));
  
  throw new stack_trace("g()"));
  

The catch Clause

• The catch clause catches thrown exceptions.

• catch ( type-spec [ name ] ) { body }

  • This syntax is similar to a one-parameter procedure definition.

    catch (exception_type ex) {
      std::cerr << ex.what();
      }
    

• When caught, the body is executed with name (if defined) as a local variable.

  • With no name, the caught exception is inaccessible.

• The ellipsis catch(...) { } catches any exception.

  • The caught exception has an unknown type.

    int main() {
      try { ... }
      catch (...) { 
        std::cerr << "Uncaught exception!"; 
        }
    

Catching Exceptions

• A catch clause with exception type ET catches the exception value of type EVT when either

  • EVT is a non-class type and EVT and ET exactly match or

  • EVT is a class type and ET is a (not necessarily proper) ancestor class of EVT .

• This is a new set of type-matching rules.

  • It's more restrictive than regular C++ type-matching rules.

  • It's less restrictive than template type-matching rules.

• Examples.

  throw 1 catch (int e) {...} throw 'a' catch (int e) {...} throw "help!" catch (string e) {...} const char * e = ... throw e catch (char * e) {...}

  class red {} class mauve : red {} class blue throw red(); catch (red e) {...} catch (mauve e) {...} catch (blue e) {...} throw mauve(); catch (red e) {...} catch (mauve e) {...} catch (blue e) {...}

The try Statement

• Only procedures with a try statement can catch exceptions.

• try { body } catch-cls . . .

• Execute the code in body and fall off the end with no exception.

• Jump from body to the catch-clss on exception

  • A normal scope exit; destructors are called.

• Search for a matching catch-cls in order.

  • An exception is considered handled as soon as a match is found.

• After executing the associated catch body, continue after the try.

• If no catch-stmt matches, terminate the current procedure and continue unwinding the stack.

Exception Problems II

• The scope of the try is not the scope of a catch.

  Declarations in the try are not accessible from catch clauses.

  try { char * cp = new char [n]; } catch (...) { delete [] cp; }

• Exception refinements - it gets confusing.

  • An exception not handled by main() causes termination.

  • An exception thrown in a catch body is like any other exception.

  • Exceptions raised in destructors cause immediate termination - no stack unwinding.

Try-Catch Behaviors

• No exception occurs
  

• An exception is thrown and caught .
  

• An exception is thrown and not caught.
  

Exceptions in Catch Clauses

• An exception raised in an catch clause is not caught by the associated try-catch statement.
  

• An exception raised in an catch clause is not caught by any succeeding try-catch statements.

• An exception raised in an catch clause may be caught by an enclosing try-catch statement.

  • The enclosing try-catch statement can be within the same function or within a calling function.

    try {
      try {
        body 
        }
      catch ( exp ) { handler }
      catch ( exp ) { handler }
      }
    catch ( exp ) { handler }
    catch ( exp ) { handler }
    

    ''

Exception Mechanism Refinements

• A catch clause can rethrow an exception using throw.

  • That's a throw without a value.

  • This is a common C++ idiom for maintaining stack-trace information within the exception.

    try { ... }
    catch (stack_trace & st) {
      st.push_back("f()");
      throw;
      }
    

• A throw clause lists the exceptions thrown by a procedure.

  r-type name ( paras ) throw ( ex1, ex2, . . . ) {...}

  • Follows the procedure's formal parameter list.

  • Only the listed exceptions can be thrown from the procedure.

    • Other exceptions cause termination.

  • A procedure throws all exceptions by default.

  • int f() throw () { . . . } throws nothing.

Exception Problems III

• Throw clauses are useful but dangerous.

  • Must list all possible exceptions.

    • Which can be hard to do.

  • Unlisted exceptions get turned into unexpected exceptions

Standard Exceptions

• The Standard defines two sets of exceptions.

  • The exception base class in <exception>.

  • A family of standard exceptions in <stdexcept>.

• The exception class is a base class for other exceptions.

  class exception {
    public:
      exception() {}
      virtual ~exception() {}
      virtual const char* what() const
        { return "class exception"; }
    };
  

• Use exception to catch any standard exception.

  try { ... }
  catch (const std::exception & ex) {
    std::cerr << ex.what() << '\n';
    }
  

Defined Standard Exceptions

• <stdexcept> defines three types of standard exceptions.

  1. Exceptions for language errors.

     • Out-of-memory errors, casting errors.

  2. Exceptions for library errors.

     • Bad index values, invalid argument values.

  3. Exceptions for runtime errors.

     • Under- or overflow errors, range errors.

• Standard exceptions have a string-argument constructor.

  class logic_error : std::exception {
    public:
      explicit logic_error(
        const std::string &);
    };
  

Defining Exceptions

• You can define an exception as a child of std::exception.

  class my_exception 
    : public std::logic_exception {
    public:
      explicit my_exception(const char *);
      const char * what() const;
    private:
      // whatever.
    };
  

• You can also inherit from a standard exception.

  class my_exception 
    : public std::exception {
    public:
      explicit my_exception(
        const std::string & emsg)
        : std::out_of_range(emsg) { }
    };
  

  • Inheriting from a standard exception is simpler than inheriting from std::exception.

Further Exception Refinements

• C++ throws several exceptions - bad_alloc in new in particular.

  • There's also a non-throwing new - this used to be standard.

• auto_pointers provide a means for automatic resource recovery on exceptions.

Points to Remember

• Don't use them - nasty, asynchronous, implicit control flow.

  • This is a controversial suggestion.

• If you do use them,

  • Make sure they indicate exceptional conditions - don't use them to exit a loop or return from a procedure; lisp programmers beware

  • Keep it as simple as possible - short throw-catch relations and simple values returned

This page last modified on 14 February 2004.