Get the skills that get the hot IT projects—fast.
home account info subscribe login search FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
[an error occurred while processing this directive]
Previous Table of Contents Next


Finally, the definition for func3() is encountered. If you recall, this function guarantees to not throw an exception. As you can see by the empty definition, the guarantee is fulfilled.

Comments

Utilizing exception specifications leads to readable and maintainable source code. The use of exception specifications also provides a form of self-documenting code. The other option you have is to furnish comments at the declaration and definition for a function that throws exceptions. The problem with that is the lack of consistency; someone might add an exception within the definition and forget to document the declaration.

Once again, an exception specification follows a function’s argument list and consists of the keyword throw, followed by a list of exception types encased within parentheses. If the exception list is empty, the function guarantees not to throw an exception.

What if a function throws an exception not specified within the exception specification list? You might think the compiler could catch the various exceptions thrown by examining the throw statements. In reality, the compiler isn’t quite that smart. The following example illustrates that fact:

void f() throw( int )
{
    int i, j , k ;
    //...
    k = i / j ;
    //...
}

This function definition states that the function will only throw an exception of type int. The problem is that a divide-by-zero exception could be thrown; the compiler can’t possibly know this. I’m sure a compiler vendor can provide a compiler switch to produce a warning message whenever it encounters a division expression. However, I assume most developers would turn that switch off, especially if developing an accounting package. The point is that you should not rely on the exception specification to tell you all the exceptions a function will throw.

What if a function throws an exception not listed within the exception specification? The library function unexpected() is called. This will happen only if the function does not handle the unknown exception. For example, you might provide the catch-all catch clause for this purpose. The default action for unexpected() is to invoke the library function terminate(). It might be in your best interest to override unexpected() so you can control its behavior. How-To 11.5 explains how to handle this situation.

11.5 Handle exceptions that are not caught or not expected?

Problem

The applications I am writing include exception handling, but exceptions are still being thrown. Is there any way that the application can process unhandled exceptions gracefully?

Technique

In this How-To, you will see how to handle exceptions that are not handled or unexpected. Although you might provide exhaustive measures to handle exceptions, there will be instances in which exceptions are missed. The example provided here will help alleviate uncaught exceptions.

Steps

1.  Move to your base source directory and create a new subdirectory named UNEXPECT.
2.  As usual, start your favorite text editor and type in the following source code:
// unexpect.cpp - program to demonstrate the
// handling of unexpected exceptions
#include <iostream>#include <cstdlib>
using namespace std ;

typedef void(*pUnExp)() ;

class ErrorClass
{
public:
    ErrorClass() ;
    void message() { cout << “ErrorClass” << endl ; }
} ;

void func( void ) throw( ErrorClass ) ;

void unexpectedHandler( )
{
    cout << “Unexpected handler!” << endl ;
    exit( 1 ) ;
}

int main()
{
    pUnExp oldHandler2 = set_terminate( unexpectedHandler ) ;
    try {
        func( ) ;
    }
    catch( ErrorClass &e ) {
        e.message() ;
    }
    return 0 ;
}

void func(  ) throw( ErrorClass )
{
    throw( double(10.0) ) ;
}


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-1999 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permision of EarthWeb is prohibited.