There is still a design decision to be made for the m3na library, but it
may arise in other projects, too: How to handle exceptions?
The situation in the m3na (numerical analysis) library is that several
exception may be raised for reasons like overflow, division by zero,
vectors of non-matching sizes, physical quantities with different units,
failing convergence. The current approach is to use a single exception
which accepts an enumeration type parameter which specifies the actual
type of error. But some of the exceptions may provide more information to
the exception handler. I can imagine two kinds of solution:
1. Use different exceptions for different errors.
2. Use one exception that is global with respect to the library. The
exception has an object as parameter and the class of the object specifies
the kind of the error. Subcl***** may contained more detailed information
for the specific error.
The first alternative allows for easy tracking of what errors can occur
when calling a routine but it may end in long RAISES lists that are hard
to maintain. The second alternative negates both statements.
Has someone experiences with this design decision or is there someone who
can give hints and conventions for using exceptions in general?
