Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
Version 1.9 Build 1367 |
|
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:
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.