Exception Handling Programmers must deal with errors and exceptional situations: User input errors Device errors Empty disk space, no memory Component errors Class might perform incorrectly invalid array index Pop() empty stack

Handling errors Most errors are unpleasant to handle The programmer should not just abort the program with an assertion failure; the user may lose all work performed during the program session Instead, the program must do the best it can to recover, and exit gracefully, only if it is really necessary.

Reaction to error Conditions Returning an error code #define FILE_OPEN_ERROR 1 #define OK 0 int openMyFile() { FILE * f = fopen(“File.txt”, “r”); if ( f == NULL ) return FILE_OPEN_ERROR; else /* Do things to a file*/ … return OK; } Advantage: simple to implement Disadvantage: Code contains a lot of error checking

Do nothing Ignore error condition Hard to debug Common approach Simpler to code Hard to debug Program might terminate or abort or produce incorrect answer Location of original problem might be hard to find Can use assert() in the debug mode Can be misleading to the caller. void Stack::push() will not push element when stack is full, however, the caller will think he successfully pushed element on the stack When coping fails, can not simply ignore the problem

Setting an Error Variable You keep a global variable, such as errno Whenever function returns, you can check errno variable if there was an error when executing the function Simple to implement Code still contains a lot of error handling code, ie: if ( errno == ERROR_NO_5 ) { printMessage(ERROR_NO_5);} The error report contains only the type of error, not the name of the offending function Two errors in rapid succession will result in the first one being overwritten Also a problem with multithreaded functions using the same variable

Printing an Error Message Reasonable in debugging mode only Simple Impacts reusability Defeats the purpose of programmatic handling of error conditions No control of program flow After error is printed, the program continues Does not always make sense to the user Example: “System error 0xff4ff45”

Aborting the Program Good for fatal error Good for debugging purposes Undesirable loss of all volatile data accumulated throughout program’s life time

Jumping to an error handler Non-local jump C setjmp() and longjmp() Provides centralized error handler Do not have to worry about stack unwinding Good approach for C programs, BAD for C++ programs When longjmp() leaves stack of the function, no destructors are called for the objects allocated on the stack.

Raising a Signal Explicitly creates Software Interrupt by calling function raise() and specifying interrupt handler Good for hardware interface Memory fault Segmentation violation Bad for typical error handling, signals should only be used for their intended purpose

Raising an Exception C++ has a convenient and safe mechanism to raise exceptions when errors are detected and to transfer both control and error information to code that is competent to deal with the situation Handles stack unwinding Calls destructors Enables a block of code to be protected Cut down on error handling code

Exceptions 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. Exceptions provide a flexible layer of flow control between the short-range return and the crude exit()

C++ exceptions When an error is encountered that cannot be handled at the point of detection, an exception can be raised with the command: throw e; Where ‘e’ could be an object, structure, or simple data type. Simple data types are not useful: throw 1; throw “Stack underflow”

C++ Exceptions The try block surrounds statements in which exceptions may be generated Example: try { // Statements in which exceptions // may be thrown } The throw statement should be executed somewhere within the try-block: either directly or from within a function called directly or indirectly from the try-block

Catch The “catch” keyword immediately follows the try-block Catch-block receives the thrown exceptions. Example try { read(); } catch( StackError s) { // Report syntax error in the input file, and close file }

Throwing exceptions in C++ Local objects should not be thrown, nor should pointers to local objects be thrown However, it is possible to throw pointers or references to dynamically generated objects, taking care that the generated object is properly deleted when the generated exception is caught Example: try{ throw new Exception(); } catch( Exception * e) { // process e delete e; // deallocate dynamically created object

Throwing references We could thrown references try { throw *new Exception(); } catch( Exception & e) { // Process e delete &e;

Catching references / Safe This is totally safe try { throw Exception(); } catch(Exception & e) { // } Output: Exception() constructor is called catch block is processed ~Exception() is called when reach end of catch-block

Catching exceptions / Unsafe This is not always safe depending on the nature of Exception destructor try { Exception e; throw e; } catch(Exception & e) { // } Output: Exception() constructor is called ~Exception() destructor is called catch block is processed ~Exception() is destructor is called the second time - Potential problem of double deallocation

Handling multiple exceptions A try block can throw different types of exceptions try { /* code */ } catch( StackError & s ) { // Process StackError } catch(MathError & m ) { // Process MathError ) }

rethrow Occasionally, we want to catch any exceptions that fly past a certain point, just to take some cleanup or protective actions try { /* … */ } catch( … ) { /* evasive action */ throw; } The throw command without an argument in-side a catch clause throws the current error again Errors that current function does not know how to handle must be re-threw

Declaration of exception throwers The declaration of a function that may throw one or more exceptions: void exceptionThrow() throw(char *, int); This function may throw char * and int exceptions Note, declaration of exceptions is not mandatory However, it declared, it notifies the user of a function that this function may throw certain exceptions, which need to be handled Without a function throw list all responsibilities of providing the correct handlers is in the hands of the designer of the program

Derived exceptions Lets assume class D derives from class B and exception of type D is thrown, then we can catch exception D using catch(B) { /* Catch exception B and any classes deriving from it */ } Note: Catch block can only specify the type

Stack unwinding The process of searching “up though the stack” to find a handler for an exception is commonly called “stack unwinding” All objects on the stack between the throw and catch point are properly destroyed by invoking their destructors This activity is of crucial importance, it is guaranteed that all destructors of abandoned stack objects are invoked thus preventing memory leak

Stack unwinding Top of the stack throw Exception e() d() c() Stack unwinds starting from function e(), d(), and c(). Destructors are called in e(), d(), and c() as stack unwinds, until exception is caught at b() Catch Exception b() a() main()

Destructors and uncaught exceptions Uncaught exceptions cause program Abort and exit Destructors should not throw exceptions If a destructor that is invoked while an exception is pending itself raises an exception, the program terminates

Exception advices Don’t throw exceptions from libraries Customers will not know that they need to catch an exception When they catch an exception they will not know how to handle it If you have to throw an exception, specify it in the prototype of the function This makes the user of the function aware that he might need to catch an exception Never throw exceptions to return the result of computation.

What exceptions should you throw? Failure of precondition Resource limitation Device failure Subsystem failure

More advice Catch those exceptions that you can handle Catch and rethrow exceptions that you can partially handle If possible, don’t use pointers and handles on the stack but place then inside objects with proper destructors Don’t throw an exception if you can continue