Getting Started Documentation Glish Learn More Programming Contact Us
Version 1.9 Build 1367
News FAQ
Search Home


next up previous
Next: The what() string Up: Note 190: Exceptions Changes for AIPS++ Previous: When to throw an exception

What exception to throw

The draft standard C++ language and library has the following exception hierarchy (indentation indicates inheritance):

bad_alloc
bad_cast
bad_exception
bad_typeid
exception
    logic_error
        domain_error
        invalid_argument
        length_error
        out_of_range
    runtime_error
        range_error
        overflow_error

Basically, the first four are thrown by various language features (for example if new fails, bad_alloc is thrown), and standard library components throw exceptions derived from exception.

The AIPS++ library, by contrast has 42 exception classes. There are seven classes alone to describe various bad things that can happen to Array classes (conformence error, indexing error and the like).

This seems excessive, given that the running program cannot meaningfully deal with most of the errors. All that is usually wanted from the exception is an error message and information about where the exception was thrown.

There are three obvious approaches:

1.
Use the standard exceptions (implemented by us for compilers without standard exceptions -- the classes are quite simple).
2.
Shadow the exception hierarchy with a similar aips_* hierarchy.
3.
Shadow the exception hierarchy, using multiple inheritance (so that the same catch could get both the aips_* and standard exception).

I prefer the first solution. The only reason I can think of to adopt the latter solutions is to embed line number and source file information. However one can intercept exceptions with a debugger, so I don't consider this advantage convenient enough to warrant the added complexity in the exception hierarchy.

We do need to allow for AIPS++ specific exceptions, so I would introduce an aips_exception class derived from exception, and perhaps an aips_io_exception derived from it. I don't think that yet more derived classes should be forbidden, however their creation should be driven by the programmer who could usefully catch such a class.


next up previous
Next: The what() string Up: Note 190: Exceptions Changes for AIPS++ Previous: When to throw an exception
Please send questions or comments about AIPS++ to aips2-request@nrao.edu.
Copyright © 1995-2000 Associated Universities Inc., Washington, D.C.

Return to AIPS++ Home Page
2006-03-28