Lecture Notes for Advanced Programming II

6 February 2003 - Exceptions

Exceptions

• The Error Problem

• Exceptions

• 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

The Error Problem

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

  box b(1, 2);  // How can box::box() handle internal errors?
  

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

  b1 = b1 + b2; // how can box::operator + () handle internal errors?
  

• The code can ignore the error.

  • Not always possible or advisable.

• The code can print an error message and die.

  • Helpful, but not always useful.

• The code can try to handle the error.

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

• The code can indicate an error some how.

  • Better, but how?

• This is the error pass-along problem.

Exceptions

• out-of-band errors - exceptions

• not propagated along parameters, return values, or globals - constructors and operators

• can be ignored by intermediate code - pass-along

Exception Basics

• the call stack

• the top of the call stack can throw an exception

• a procedure in the call stack can catch an exception

• the procedure closest to the top wanting the exception gets it

• the intervening processes are unwound - the catching process is the new call-stack top

• the throwing and intervening processes are terminated immediately

Exception Problems

• intervening processes have no chance to clean up

• coordinated exceptions among independent modules requires work

Basic Exception Mechanisms

• throw, catch, and try

The throw Statement

• The throw statement lauches (throws) an exception.

• throw expr throws the value expr as an exception.

• like return in syntax and semantics

• expr can be a value of any type

The catch Statement

• catch ( type-spec [ name ] ) { body } - catches a thrown exception

• with no name, the actual exception is unknown

• exception types must match exactly - with no conversions but with polymorphism

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

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

The try Statement

• try { body } catch-stmt . . .

• execute the code in body - fall off the end with no exception

• jump from body to the catch-stmts on exception - a normal scope exit; destructors are called

• search for a matching catch-stmt 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 up the stack

Exception Problems II

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

• 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

Exception Mechanism Refinements

• exception class values

  • <exception> defines the virtual class exception

    • defines char * exception::what(void) const

  • <stdexcept> defines some derived exceptions - runtime_error and logic_error

• a catch handler can rethrow an exception using throw

• a procedure can list the exceptions it throws with a throw clause

  • throw ( ex1, ex2, . . . )

  • follows the procedure's formal parameter list

  • only the listed exceptions can be thrown from the procedure - other exceptions cause termination

  • by default a procedure can throw all exceptions

Exception Problems III

• throw clauses are useful but dangerous - must list all possible exceptions; unlisted exceptions get turned into unexpected exceptions

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.

• 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 8 February 2003.