Differences with Java Exceptions 1 Exception handling in

Differences with Java Exceptions 1 Exception handling in C++ and Java are very similar: n Same try block structure with catch handlers n Same throw statements n Same stack unwinding model The are also several differences: n No Throwable or Exception base classes, so you have to build your own exception hierarchy n As a result, there are no common operations supported by all exceptions (i. e. , they are not all printable, do not all contain a message, etc. ) n Can throw primitive types too n No stack traces n Exceptions are only created by throw statements, so most unexpected failures do not result in exceptions n No finally blocks, so you must guard against unexpected exceptions that occur within your catch blocks Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Standard C++ Exceptions n Exceptions 2 Exceptions thrown by standard C++ library code: Note that not every exception in C++ is derived from exception. (Thus the base exception type cannot be used to catch every exception in C++. ) The base exception class declares a const char* what() method for output of an exception message. Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Exceptions for Access Violations Exceptions 3 The iterator for a DList. T template may be modified to throw an exception when an invalid instance of it is dereferenced: class Illegal. Access {}; . . . // exception object class iterator { public: iterator() { Position = NULL; }. . . T& operator*() { if ( Position == NULL ) throw Illegal. Access(); return Position->Element; }. . . Now, dereferencing an invalid iterator will produce behavior consistent with pointers. Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Exceptions for Arithmetic Errors Exceptions 4 Exceptions may also be used to mimic aborted hardware errors: #include <limits> using namespace std; class Arithmetic. Exception {}; Negative. Radicand : public Arithmetic. Exception {}; Divide. By. Zero : public Arithmetic. Exception {}; Convergence. Failure : public Arithmetic. Exception {}; double Square. Root(double A) throw(Arithmetic. Exception) { if ( A < 0. 0 ) throw Negative. Radicand(); int Iterations = 0; const int ITERATIONLIMIT = 100; double EPS_DBL = numeric_limits<double>: : epsilon(); double MIN_DBL = numeric_limits<double>: : min(); . . . Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Exceptions for Arithmetic Errors Exceptions 5 . . . double Xk, Xkp 1; Xkp 1 = A; while ( fabs(Xkp 1 * Xkp 1 - A) > EPS_DBL ) { Xk = Xkp 1; if ( fabs(Xk) < MIN_DBL ) throw Divide. By. Zero(); else Xkp 1 = Xk / 2. 0 + A / (2. 0 * Xk); Iterations++; if ( Iterations > ITERATIONLIMIT ) throw Convergence. Failure(); } return Xkp 1; } Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Hierarchy of Exceptions 6 Using an inheritance hierarchy of exception objects allows for flexible control in the handler: #include <limits> using namespace std; class Arithmetic. Exception {}; Negative. Radicand : public Arithmetic. Exception {}; Divide. By. Zero : public Arithmetic. Exception {}; Convergence. Failure : public Arithmetic. Exception {}; Always catch object-valued exceptions by reference (preserves polymorphism, eliminates copy-construction) try { root } catch ( cout } = Square. Root(x); Omit parameter name to avoid compiler warnings about unused identifiers, if you do not refer to it in the handler Negative. Radicand& N ) { << "caught a Negative. Radicand" << endl; Arithmetic. Exception& A ) { << "caught a general arithmetic exception" << endl; Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ

Exception safety n n Exceptions 7 Exception safety in a component means that it exhibits reasonable behavior when an exception is thrown during its execution This includes all the usual expectations for error-handling: – Resources should not be leaked – The program should remain in a well-defined state so that execution can continue For most components, it also includes the expectation that when an error is encountered, it is reported to the caller The hardest part: usually ensuring the program remains in a well-defined state – Often, individual methods must either run to completion, or have no effect at all – Operations can never throw an exception and leave object(s) in an invalid intermediate state—this includes exceptions thrown indirectly by calling lower-level operations! Computer Science Dept Va Tech January 2002 OO Software Design and Construction © 2002 Mc. Quain WD & Keller BJ