1 / 28

Advanced Program Design with C++

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.

cengel
Download Presentation

Advanced Program Design with C++

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Advanced Program Design with C++ Part 10: Exception handling Joey Paquet, 2007-2017

  2. 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-2017

  3. 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. • 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-2017

  4. Exception handling: example C programs with error handling #include<stdio.h> #include<errno.h> #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); perror("Error printed by perror"); 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-2017

  5. 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 separate code should be provided for abnormal cases, i.e. cases outside of the function’s specifications of normal behavior. Joey Paquet, 2007-2017

  6. 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-2017

  7. Exception handling: try-throw-catch • Syntactically, handling exceptions in C++ is made through of the try-throw-catchkeyword 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 triesto 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-2017

  8. 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. • 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-2017

  9. Exception handling: try-throw-catch • A throw statement is similar to a method call: 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-2017

  10. Exception handling: try-throw-catch • When an exception is thrownand the exception handling mechanism takes over, it tries to find a corresponding catch block to handle the exception. • Acatch block has at most one parameter. • The exception object thrown is passed to the catchblock 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. catch(Exception e) { ExceptionHandlingCode } Joey Paquet, 2007-2017

  11. 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 mean 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-2017

  12. 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. • 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-2017

  13. 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. void g(){ // to be deleted first during stack unwinding // including parameters passed as value throwstd::exception(); } void f(){ // to be deleted second during stack unwinding // including parameters passed as value g(); } int main(){ // not to be deleted during stack unwinding try { // to be deleted third during stack unwinding f(); } catch (...){ } // resume here after handling } Joey Paquet, 2007-2017

  14. 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-2017

  15. 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-2017

  16. 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-2017

  17. Exception handling: standard exceptions Joey Paquet, 2007-2017

  18. 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-2017

  19. Exception handling: exception classes hierarchy Joey Paquet, 2007-2017

  20. 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-2017

  21. Exception handling: example • An industrial boiler in 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-2017

  22. 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. • Could there be? 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-2017

  23. 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-2017

  24. 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-2017

  25. 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-2017

  26. 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 traversal and unwinding is roughly comparable to the cost of a function call/resolution. • 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-2017

  27. 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 to create resource leaks. • Destructors should never be allowed to throw an exception if their code throws an exception, it should keep it contained and resolved locally. • Dynamic memory allocation makes things more difficult, as stack unwinding does not take into consideration dynamically allocated local variables. Joey Paquet, 2007-2017

  28. 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. Joey Paquet, 2007-2017

More Related