Introduction to Exceptions

• This is chapter 14, Handling Errors
  • Pages 433 - 461
  • Save the rest of the chapter for later.
• I have decided to talk about smart pointers.
  • But one of the motivating factors is exceptions.
• Furthermore we need exceptions for our current project
  • What do you do when someone attempts to Pop or Top an empty stack?
    • This is a problem.
    • Should you print an error message?
      • You don't know the application.
      • And all this does is postpone an error
    • Should you return an invalid value?
      • But this has problems.
    • Should we add another parameter, a valid flag for example?
• In general, none of these solutions are good.
• Exception handling is away to deal with "exceptional but not unexpected situations." (p 433)
  • We know that someone may want to pop an empty stack.
  • But we don't want to do the wrong thing.
• Stroustrup says "The fundamental idea is to separate detection of an error(which should be done in the called function) from the handling of an error (which should be done in the calling function) while ensuring that a detected error cannot be ignored..."
• The exception mechanism is completely a c++ thing.
  • An exception occurs when an anticipated error condition is encountered.
  • They return control up the stack to where the user has built a mechanism to deal with this error.
  • The important things are
    • They bypass the normal return mechanisms
    • They do, however, call destructors of any objects that go out of scope.
• The basic mechanism
  • an additional reference

  • try {
        //code which  may produce exceptions
        // most likely to include a function call which could produce an exception
    } catch (type_specifier identifier) {
        // code to deal with the exception caught
    } catch (type_specifier identifier) {
        // code to deal with the exception caught
    } ...
    } catch (...) {
        // code to deal with any exception
    } 

  • You only need one handler (catch)
    • But you can detect different types of errors with multiple handlers
      • More on this later
    • The handler (...) catches everything
      • This is like a default in a switch statement.
    • The first handler to match is called (used) and all others are skipped..
  • If you don't match the exception, the program will abort.
• The other side
  • reference

  • throw expression;
           

• Some simple examples
  • Look at the code examples.
• Exception types
  • Can be anything.
  • You should catch by reference.
    • To avoid slicing, which we will discuss later.
  • There is a standard exception hierarchy.
    • Reference
    • 
    • This is a "is-a" relationship we will discuss later.
    • Anything lower can be caught by anything higher.
    • You need to include exception.
    • Most have a constructor that takes a string, the user message
    • All have a .what method that prints a user message.
    • This is illustrated in heir.cpp
• We will return to exceptions in the future.