290 likes | 303 Views
Advanced Program Design with C++. Part 10: Exception handling. Exception handling: introduction. Programs are meant to work correctly within their specifications . However, a program might be faced with unforeseen circumstances that are outside of its specifications.
E N D
Advanced Program Design with C++ Part 10: Exception handling Joey Paquet, 2007-2018
Exception handling: introduction • Programs are meant to work correctly within their specifications. • However, a program might be faced with unforeseen circumstances that are outside of its specifications. • Unforeseen situations may come: • Externally from the environment of the program • When a user or software client tries to use the software outside of its specified usage characteristics. • When the program tries to use another piece of software and is faced with unforeseen behavior. • Internally from its own execution • When the program misbehaves due to an internal logical error and/or being in an inconsistent state. • A robust program should be able to handle all kinds of circumstances, foreseen or unforeseen, whether they are coming from the exterior or are a result of its own faults. Joey Paquet, 2007-2018
Exception handling: introduction • Exception handling is a mechanism that allows two separately developed program components to communicate when a program anomaly is encountered during the execution of the program. • The code for the normal program execution in normal situations (i.e. the regular code). • The code for program execution after encountering an abnormal situation. • Such communication upon erroneous behavior has been long part of programming practice in the form of error codes and error handling. • In error handling, functions set or return special error codes in case of malfunction and finish execution normally. • It is then assumed that any function that might be affected will use the error code and react by handling the error i.e. to continue normal execution despite the error. Joey Paquet, 2007-2018
Exception handling: example C programs with error handling #include<stdio.h> #include<errno.h>//system error numbers #include<string.h> externinterrno; int main() { FILE * pf; interrnum; pf = fopen("unexist.txt", "rb"); if (pf == NULL) { errnum = errno; fprintf(stderr, "Value of errno: %d\n", errno); // C Library function perror() perror("Error printed by perror"); // C Library function strerror() fprintf(stderr, "Error opening file: %s\n", strerror(errnum)); } else { fclose(pf); } return 0; } #include<stdio.h> #include<stdlib.h> main() { int dividend = 20; int divisor = 5; int quotient; if (divisor == 0){ fprintf(stderr, "Division by zero! Exiting...\n"); exit(EXIT_FAILURE); } quotient = dividend / divisor; fprintf(stderr, "Value of quotient : %d\n", quotient); exit(EXIT_SUCCESS); } Joey Paquet, 2007-2018
Exception handling: introduction • However, error handling introduce confusion as it does not enable to separate normal behavior from error-handling behavior. • To be more structured, functions should be first programmed according to the specifications of their normal behavior, and clearly separated code should be provided for abnormal cases, i.e. cases outside of the function’s specifications of normal behavior. Joey Paquet, 2007-2018
Exception handling: introduction • The first programming language to provide the early concept of exception handling was LISP in the early 1960. PL/1 later extended the concept in the early 1970s. • An exception is a data structure that is generated when a special erroneous condition is met, that contains information about the nature and context of this erroneous condition. • Exceptions are processed by an exception handling mechanism that only takes effect when an exception has been identified. • The exception handling mechanism will then take over the normal execution mechanism until the exception handling is resolved. • If the exception can be properly resolved, normal execution is resumed. • If the exception cannot be resolved, the program execution is terminated. Joey Paquet, 2007-2018
Exception handling: try-throw-catch • Syntactically, handling exceptions in C++ is made through of the try-throw-catch keyword trio, which is highly similar to what is used in Java. • The try block contains a part of the code for the normal execution of the program. • It is called a try block because it tries to execute the normal execution behavior, but where something is likely to be subject to exceptionally erroneous behavior. Code that will/should not throw any exception try{ CodeThatMayThrowAnException } Code that will/should not throw any exception Joey Paquet, 2007-2018
Exception handling: try-throw-catch • Whenever a piece of code identifies an exceptionally wrong situation, it can create an exception and trigger the exception handling mechanism by using a throw statement: throwvalue Or more specifically throw new ExceptionClassName(PossiblySomeArguments); • When an exception is thrown, the normal execution of the surrounding try block is stopped and the exception handling mechanism takes over the execution of the program. • Normally, the flow of control is transferred by the exception handling mechanism to another portion of code known as a catch block. • In C++, the value thrown is the argument to the throw operator, and can be any value (possibly an instance of some exception class). Joey Paquet, 2007-2018
Exception handling: try-throw-catch • A throw statement is similar to a function call that takes an object as a parameter, then identifies it as an exception to be handled: thrownew ClassName(“Some Descriptive String”); • In the above example, an object of class ClassName is created using a string as its argument (assuming that it has such a constructor defined) and used as an exception object. • Unlike Java, C++ can use any value as an exception, and classes used to instantiate exceptions do not need to be subclasses of the standard exception class. • The throw statement has the effect of temporarily halting the normal execution of the program and handing it over to the exception handling mechanism. Joey Paquet, 2007-2018
Exception handling: try-throw-catch • When an exception is thrown and the exception handling mechanism takes over, it tries to find a corresponding catch block to handle the exception. catch(Exception e) { ExceptionHandlingCode } • A catch block has at most one parameter. • The exception object thrown is passed to the catch block using a similar mechanism as for a function call’s parameter passing. • The type of the catch block’s exception object parameter determines what kind of exception a catch block is meant to handle. • The execution of the catch block is called catching the exception, or handling the exception. • A catch block is often called an exception handler. Joey Paquet, 2007-2018
Exception handling: try-throw-catch • Any catch block is attached to a specific try block. • A catch block is an exception handler that is meant to handle some exception thrown in the try block it is attached to. • The type of exception it is meant to handle is specified by its parameter type. • A single try block can be attached to as many catch blocks as there are different kinds of exceptions potentially thrown in the try block’s code. • A catch block meant to catch all exceptions is signified using an ellipse (…) as a parameter. try { // Code that potentially throws some exception(s) } catch (ExceptionType1 e){ // Exception handling code for ExceptionType1 } catch (ExceptionType2 e){ // Exception handling code for ExceptionType1 } catch (...){ // Exception handling code for any other type of // exception not handled by the preceding catch blocks } Joey Paquet, 2007-2018
Exception handling: try-throw-catch • When a try block is executed, three things can happen: • No exception is thrown in the try block • The code in the try block is executed to the end of the block. • The catch blocks are skipped. • The execution continues with the code placed after the catch block. • An exception is thrown in the try block and caught in a catch block • The rest of the code in the try block is skipped. • Control is transferred to a following catch block. • The thrown object is passed to the catch block using parameter passing. • The code in the catch block is executed. • Normal execution resumes using the code that follows all catch blocks. • An exception is thrown in the try block and there is no corresponding catch block to handle the exception • The rest of the code in the try block is skipped. • The function throws the exception to its calling function. • The calling function either catches the exception using a catch block, or throws the exception to its calling function, in which case the rest of the code in the function is skipped and stack unwinding is applied on this function’s stack frame. A corresponding catch block is looked for in every function down the function call stack. • If all the called functions fail to catch the exception, the exception will eventually be thrown all the way to the main function. If the main function cannot catch the exception, the program ends, itself throwing the exception. Joey Paquet, 2007-2018
Exception handling: stack unwinding • Once the exception handling mechanism takes control as a throw statement is executed, control moves from the throw statement to the first catch statement that can handle the thrown type. • Once the control goes to the catch handler, a process known as stack unwinding is used to delete all the automatically allocated local variables that were used between the execution site where the exception was thrown and the execution site where the exception is caught. • Stack unwinding does not delete heap-allocated values. • Hence, stack-allocated variables in code before the location where exception is thrown outside of a catch will lead to a memory leak. • Solution: avoid them or create a try-catch to allocate/deallocate them. Joey Paquet, 2007-2018
Exception handling: stack unwinding: example stringwhichToFail; classMyClass { public: string name; MyClass(conststringnewName) : name(newName) { cout<<"in MyClass constructor: "<< name <<endl; }; ~MyClass() { cout<<"In MyClass destructor: "<< name <<endl; } }; void g() { // to be deleted first during stack unwinding // including parameters passed as value MyClass mc4("mc4"); if (whichToFail=="g") throw std::exception(); MyClass mc5("mc5"); } void f() { // to be deleted second during stack unwinding // including parameters passed as value MyClass mc2("mc2"); if (whichToFail=="f") throw std::exception(); g(); MyClass mc3("mc3"); } int main() { cin>>whichToFail; // not to be deleted during stack unwinding MyClass mc1("mc1"); try { // to be deleted third during stack unwinding MyClass mc6("mc6"); if (whichToFail=="main") throw std::exception(); f(); MyClass mc7("mc7"); } catch (...) { MyClass mc8("mc8"); } // resume here after handling the exception MyClass mc9("mc9"); } Joey Paquet, 2007-2018
Exception handling: stack unwinding • If exceptions are thrown in constructors, only the parts of the object that were yet fully constructed are destructed during stack unwinding. charclassToThrow; class D { public: D(){ cout << "Constructor D()" << endl; if (classToThrow == 'D') throwclassToThrow; } ~D(){ cout << "Destructor ~D()" << endl; } }; class C { public: C(){ cout << "Constructor C()" << endl; if (classToThrow == 'C') throwclassToThrow; } ~C(){ cout << "Destructor ~C()" << endl; } }; class B { public: B(){ cout << "Constructor B()" << endl; if (classToThrow == 'B') throwclassToThrow; } ~B(){ cout << "Destructor ~B()" << endl; } }; class A : public B { public: C mC1; D mD2; A() { cout << "Constructor A()" << endl; if (classToThrow == 'A') throwclassToThrow; } ~A(){ cout << "Destructor ~A()" << endl; } }; int main(){ while (true){ cout << "Enter a class name : "; cin >> classToThrow; try{ A* a = new A(); delete a; } catch (char c){ cout << "catching " << c << endl; } } system("PAUSE"); return EXIT_SUCCESS; } Joey Paquet, 2007-2018
Exception handling: exception specification • Exception specifications: throw clause • Funtiondivide can only throw exceptions of DivideByZeroException. • Function safeFunction cannot throw any type of exception. • Function freeForAll can throw any type of exception. • Seems a great idea, but this is extremely restrictive and leads to very tedious programming, as thrown exceptions tend to propagate. • Problem: Any function that calls a function that may throw either needs to make the call in a try block and catch the exception, or itself have a throw clause that specifies that it may throw. • This is referred to in Java as the “catch or declare rule”. double divide(double dNumerator, double dDenominator) throw (DivideByZeroException); void safeFunction(int iFoo) throw(); voidfreeForAll(intiBar); Joey Paquet, 2007-2018
Exception handling: exception specification • In C++, exception specification clauses do not mean that the code executed by the function is guaranteed to throw only exception listed in its throw list. • Rather, it means that the exception handling mechanism will make the program call unexpected() if a function throws an exception type that in not listed in its throw clause. • The default behavior of unexpected() is to call terminate(), which abruptly stops the program’s execution. • This verification is only used at runtime. The compiler will not verify that all exceptions potentially thrown by the code included in a function only throw exceptions listed in its throw list. • Exception specification has been eliminated in C++11. Joey Paquet, 2007-2018
Exception handling: standard exceptions Joey Paquet, 2007-2018
Exception handling: custom exception classes • Any class can be thrown as an exception. • All that is really needed to be used as an exception is to be a type. • Custom exception classes can be derived from the standard exception class. • The only particularity of this class is that it offers a members function what() to return a string that allows the programmer to store a descriptive message on the nature of the circumstances that led to the error. • Generally, this string is passed to the constructor upon creation of the exception. classHardwareException : publicexception { public: HardwareException(); char * exc_time; constchar * what() const; }; classActuatorException : publicHardwareException { friendostream& operator<<(ostream &output, constActuatorException &e); public: ActuatorException(HardwareState s); HardwareStatehw_State; }; classSensorException : publicHardwareException { friendostream& operator<<(ostream &output, constSensorException &e); public: SensorException(int v); intvalueRead; }; classOverloadPressureException : publicSensorException { public: OverloadPressureException(int v); }; classStuckValveException : publicActuatorException { public: StuckValveException(HardwareState s); }; Joey Paquet, 2007-2018
Exception handling: exception classes hierarchy Joey Paquet, 2007-2018
Exception handling: custom exception classes implementation • An exception class can be made to store any other useful information, e.g. the time where the exception was thrown. • The what() function can also be overridden to provide information otherwise than assuming the programmer to provide a string. • As for any other class, one can also overload operators to manipulate user-defined exceptions, e.g. stream input/output operators. HardwareException::HardwareException() { time_t now = time(0); exc_time = ctime(&now); } constchar * HardwareException::what() const { returntypeid(*this).name(); } ActuatorException::ActuatorException(HardwareStates) : hw_State(s){ cout << "in ActuatorException constructor" << endl; }; ostream& operator<<(ostream &output, constActuatorException& e) { output << e.hw_State << " @ " << e.exc_time << " : " << e.what() << endl; returnoutput; } SensorException::SensorException(intv) : valueRead(v){}; ostream& operator<<(ostream &output, constSensorException& e) { output << e.valueRead << " @ " << e.exc_time << " : " << e.what() << endl; returnoutput; } Joey Paquet, 2007-2018
Exception handling: example • An industrial boiler controlled by software. • It is connected to a pressure sensor and a pressure release valve. • It keeps the pressure within an acceptable range. • If the sensor is misbehaving, it shuts down the boiler by opening the valve. • If the valve is stuck, it calls an emergency. • It keeps a log of the pressure readings, as well as another log for operational events. • The hardware drivers can throw exceptions. • For security, the boiler controller should be shielded from those exceptions. • Thus, an exception handling layer is added. Joey Paquet, 2007-2018
Exception handling: example • Boiler: connected to a temperature sensor and pressure release valve. • Reports pressure in pressureReportFile. • Reports errors in EmergencyFile. • Repeatedly reads the pressure. • No exception handling here. Boiler::Boiler(){ cout << "in Boiler constructor" << endl; emergencyFile.open("EmergencyFile.txt"); emergencyFile << "STARTING BOILER CONTROLLER" << endl; pressureReportFile.open("pressureReportFile.txt"); pressureReportFile << "STARTING BOILER CONTROLLER" << endl; ps = newPressureSensorConnector(newPressureSensor(), this); prv = newPressureReleaseValveConnector(newPressureReleaseValve(stuck), this); boilerState = safe; srand(time(0)); } voidBoiler::shutdown(){ cout << "in Boiler::shutdown" << endl; emergencyFile << "Engaging shutdown procedure." << endl; prv->open(); emergencyFile << "BOILER CONTROLLER WAS SHUT DOWN" << endl; pressureReportFile << "BOILER CONTROLLER WAS SHUT DOWN" << endl; } voidBoiler::start(){ cout << "in Boiler::start()" << endl; inti; while (boilerState == safe){ Sleep(1000); i = ps->getPressure(); } } Boiler::~Boiler(){ emergencyFile.close(); pressureReportFile.close(); } classBoiler { public: Boiler(); ~Boiler(); void shutdown(); void start(); PressureSensorConnector* ps; PressureReleaseValveConnector* prv; ofstreamemergencyFile; ofstreampressureReportFile; BoilerStateboilerState; }; enumActuatorState { opened, closed }; enumBoilerState { safe, unsafe, critical }; enumHardwareState { operational, stuck }; int main() { Boiler b; b.start(); } Joey Paquet, 2007-2018
Exception handling: example • PressureSensor: hardware component that reports pressure reading. If out of range, throw exception. • Connected to the boiler using a connector that reports pressure readings and catches the exceptions thrown by the sensor and reports them. intPressureSensor::getPressure(){ cout << "in PressureSensor::getPressure()" << endl; int pressure = rand() % 105 - 1; if (pressure < 0) { cout << "about to throw NegativePressureException" << endl; thrownewNegativePressureException(pressure); } if (pressure > 100) { cout << "about to throw OverloadPressureException" << endl; thrownewOverloadPressureException(pressure); } return pressure; } PressureSensorConnector::PressureSensorConnector(PressureSensor *ps, Boiler *b) : ps(ps), b(b) { cout << "in PressureSensorConnector constructor" << endl; }; intPressureSensorConnector::getPressure(){ cout << "in PressureSensorConnector::getPressure()" << endl; int pressure = 999; try{ pressure = ps->getPressure(); time_t now = time(0); char *read_time = ctime(&now); b->pressureReportFile << pressure << " @ " << read_time << endl; } catch (SensorException* e){ cout << "catching SensorException in PressureSensorConnector::getPressure()" << endl; b->emergencyFile << *e; b->boilerState = unsafe; b->shutdown(); } return pressure; } classPressureSensor { public: intgetPressure(); }; classPressureSensorConnector { private: PressureSensor* ps; Boiler* b; public: PressureSensorConnector(PressureSensor *ps, Boiler *b); intgetPressure(); }; Joey Paquet, 2007-2018
Exception handling: example • PressureReleaseValve: hardware component that opens/closes the boiler’s container. If the valve is stuck throw an exception. If the valve is stuck closed, put the boiler in critical state. PressureReleaseValve::PressureReleaseValve(HardwareStates = operational) : hw_state(s), act_state(closed){}; voidPressureReleaseValve::close(){ // assume that the valve can become stuck (see full code for random factor) if (hw_state == stuck && act_state == opened) { thrownewStuckValveException(hw_state); } else { act_state = closed; } } voidPressureReleaseValve::open(){ // assume that the valve can become stuck (see full code for random factor) if (hw_state == stuck && act_state == closed) { thrownewStuckValveException(hw_state); } else { act_state = opened; } } PressureReleaseValveConnector::PressureReleaseValveConnector (PressureReleaseValve *prv, Boiler *b) : prv(prv), b(b){}; voidPressureReleaseValveConnector::close(){ try{ prv->close(); } catch (StuckValveException e) { b->emergencyFile << e; } } voidPressureReleaseValveConnector::open(){ try{ prv->open(); } catch (StuckValveException* e) { b->boilerState = critical; b->emergencyFile << *e; } } classPressureReleaseValve { public: PressureReleaseValve(HardwareState s); void close(); void open(); private: ActuatorStateact_state; HardwareStatehw_state; }; classPressureReleaseValveConnector { private: PressureReleaseValve* prv; Boiler* b; public: PressureReleaseValveConnector( PressureReleaseValve *prv, Boiler *b); void close(); void open(); }; Joey Paquet, 2007-2018
Exception handling: significance • Does the exception handling mechanism solve our error handling problems? • No, it is only a mechanism. • Does the exception handling mechanism provide a radically new way of dealing with errors? • No, it simply provides a formal and explicit way of applying the standard techniques. • The exception handling mechanism • Makes it easier to adhere to good programming practices. • Gives error handling a more regular style. • Makes error handling code more readable. • Makes error handling code more amenable to tools. [Bjarne Stroustrup] Joey Paquet, 2007-2018
Exceptions: overhead • The exception mechanism has a very minimal performance cost if no exception is thrown. • If an exception is thrown, the cost of the stack unwinding is roughly comparable to the cost of the normal function call/resolution mechanism. • Additional data structures are required to track the call stack after a try block is entered, and additional instructions are required to unwind the stack if an exception is thrown. • In most scenarios, the cost in performance and memory footprint is not significant. • The adverse effect of exceptions on performance is likely to be significant only on very memory-constrained systems, or in performance-critical loops where an exception is likely to be thrown regularly and the code to handle it is tightly coupled to the code that throws it. Joey Paquet, 2007-2018
Exceptions: overhead • The real cost of exception handling is in the difficulty of designing exception-safe code. • Constructors that throw exceptions are problematic: if a constructor fails, the object is not created, which makes it hard to recover from. This is even more problematic with class hierarchies, which require a sequence of constructors to succeed in order for an object to be fully constructed. In C++, an object is either successfully fully constructed or it does not exist. • Even more problematic is that if an object is not fully created, its destructor is never called, leading to partially-created objects that create resource leaks. • Destructors should never be allowed to throw an exception if their code throws an exception, it should keep it contained and be resolved locally. • Dynamic memory allocation makes things more difficult, as stack unwinding does not take into consideration dynamically allocated local variables. Joey Paquet, 2007-2018
References • Andrew Koenig and Bjarne Stroustrup. 1993. Exception handling for C++. In The evolution of C++, Jim Waldo (Ed.). MIT Press, Cambridge, MA, USA 137-171. • Goodenough, John B. Structured exception handling. Proceedings of the 2nd ACM SIGACT-SIGPLAN symposium on Principles of programming languages - POPL '75. pp. 204–224. doi:10.1145/512976.512997 • tutorialspoint.com. C++ Exception Handling. • tutorialspoint.com. C – Error Handling . • informit.com. Stanley B. Lippman, Josée LaJoie, Exception Handling in C++. • Microsoft Developer Network. C++ Exception Handling. • Microsoft Developer Network. Exceptions and Stack Unwinding in C++. • Wikibooks. C++ Programming, C++ Programming/Exception Handling. • Bjarne Stroustrup. The C++ Programming Language. Chapter 13: Exception Handling. Addison-Wesley. Fourth Edition, 2014. • A Coder’s Journey. Top 15 C++ Exception Handling Mistakes and How to Avoid Them. Joey Paquet, 2007-2018