Exception Handling

That's great, get rid of the picture, I want to print this

Exception Handling Presentation Overview

See our Bibliography
Introduction to Exception Handling
  • Different Models:
  • What to take into account:
    Back up to the top
    C++ & Object-Oriented Exception Handling

    Exception is a way of representing unexpected events. This mechanism of handling unexpected events in Object Oriented languages is based on a representing an exception as an object of some type and some specific value. The two major Object Oriented languages that implement Exception handling are C++ and Java. Java designers have implemented exception handling mechanism based on C++. Thus looking at how exception handling is implemented in C++ pretty much takes care of exception handling paradigm in Object Oriented languages except for the few additional features, that we will talk about, in Java.

    C++ Exception Handling:
    Any failure occurred during execution of a C++ program is directed back dynamically to the sector of the code prepared to handle it. In doing this, all the work in progress is terminated. C++ uses a system of objects with types. Once the exception is represented as an object, it may contain whatever information will help in reporting or recovering from exception.

    A function throws exception in the form of an object of some type and a value. This object then travels upward through the current function to the current functions caller, to the callers caller, and so on until a function is found to catch the exception. During this process, stack containing all the running function is looked at. If the function being checked is not able to catch the exception, the function, along with its local variables, are terminated by calling their destructors.

    There are three ways to represent an exception: Syntax:

    try and catch

    To catch an exception thrown within code, the code should be enclosed in a try-block. The try-block is then followed by handlers, i.e. the catch clauses.

    void might_break(int i)
      if (i == 1) throw "something!";
       if (i == 4) throw 4;
      // ...
        void p (int i)
    { //
       try    // begin try block
      catch (const char *p) // begin handler
        cout << "caught " << p;
        // fix whatever...
      } // end try block
    } // end handler

    In this example, calling p with a value of anything other than 1 or 4 causes the program to execute normally, with no exception thrown. If p is called with a value of 1, the might_break function throws a string object to the p handler, which prints caught something!.

    If p is called with 4, an int is thrown. Because p cannot catch values of type int, the search for a handler proceeds up the call stack until an appropriate handler can be found. If nothing on the stack can handle an int, program execution terminates immediately after calling the std::terminate function.

    Slicing Problem:
    The parameter to catch is initialized the same way a function argument is initialized. The handler thus forces a parameter passed to it to its base type. In doing so the original exceptionUs type is lost and problem comes up in handling it as it has been cast to its base type. This can be avoided by passing parameters by reference or by passing the pointer that points to the parameter to the handler.

    An exception handler might not know how to deal with an exception completely and may want pass it along to the next handler. This can be achieved by enclosing a throw from within the catch block. Eg.
    Glow:: read(..args..){
      Try {
         This and that..
         Return whatever..

      catch ( I.) // catch anything
      throw; //rethrow the current exception..

    Exception Specifications:
    If the program is organized around semantic domains, the domain can be made into exception-tight compartments that stop the flow of all exceptions except that specifically meant to propagate. Eg.
       // beef() may throw bam, wham, cow.    Beef() throw(bam, wham, cow) {}

    Terminate() and Unexpected():
    An attempt to throw an exception before another has reached its handler, or failing to catch an exception causes the function terminate() to be invoked. Violating an exception specification causes the function unexpected() to be invoked.

    C++ exception handling represents a termination model, which means that program execution never proceeds past a throw.M

    Run Time Considerations:
    C++ optimizes the implementation of exception handling for normal execution by incurring the overhead for exceptions when throwing it. Applications that have try blocks and that run without causing exceptions incur only slight overhead as follows:

    Implicit handlers:
    functions without explicit handlers may have implicit handlers. The compiler creates a handler for each automatic object that has a destructor. The compiler also creates handlers for constructors that initialize subobjects that have destructors. In such a constructor, the compiler creates a handler for each member with a destructor, and a handler for each base class with a destructor.

    If one really doesn't want to use any resources in handling exceptions, C++ lets one use the -nocleanup option. This option suppresses generation of such implicit handlers, which results in a slightly smaller executable file. Use the nocleanup option for programs that do not use exception handling or do not require destruction of automatic objects during exception processing.

    Thus, in using exception handling mechanisms, some memory resources are used up. Some of the ways to use as little resource as possible are as follows;
    Exceptions and Threads:
    C++ exceptions are thread safe. This means that multiple threads within a process can throw and catch exceptions concurrently. However, exceptions do not propagate from one thread to another, nor can one thread catch an exception thrown by another thread.

    Exception Handling in Java:
    Syntactically, Java is very much similar to C++. The one additional feature Java has is the 'finally' block which is executed in every case. However, in terms of model, it is completely different than C++. C++ uses destructors to release the resources utilized. Java, on the other hand has automatic garbage collection and uses finalize() to do all the clean up. Finalize() is not called until garbage collector releases memory and in instance when memory is not released, finalize() is not called which is taken as a serious problem. Thus, exception handling in C++ is more efficient and reliable than Java.

    Back up to the top
    Ada: An Imperative Language Back up to the top
    Perl: A modern Scripting Language Back up to the top
    Comparisons of the Programming Languages Back up to the top
    Creative Uses of Exception Handlings Back up to the top
    Future Directions in Exception Handling & Wrap-up

    What will the exceptions of the twenty-first century be like? No one knows for sure, but here are some ideas to consider:

    Back up to the top
    The End. This compilation of notes was written by Jared Seaman, 5/6/99.