CoCoA » CoCoALib

The current error mechanism allows for error messages in different languages -- and the user can change language arbitrarily often at run-time. Do we want to maintain this capability? [bear in mind that the we do not really use the existing multi-language mechanism at all]

Perhaps I should investigate how hard it would be to produce a design that could easily be extended to a multi-language impl if we chose to do so....

NOTE (2013-07-09) if error mesgs are to be composed of a main "generic" message with an (optional) supplementary message, there will have to be a way of translating the supplementary messages into the chosen language -- this looks to be problematic!

The following URL http://stackoverflow.com/questions/9387377/how-to-design-exception-types-in-c suggests deriving all user exception types from std::runtime_error. It also suggests avoiding needlessly fancy inheritance structures -- the inheritance structure serves only to allow the caller to easily catch/handle some errors and not others.

NOTE (2013-07-10) we may find it convenient to use C++ inheritance in our implementation but without this inheritance being publicly guaranteed (i.e. no user should rely on it).

BOOST exceptions are quite sophisticated. Since exceptions currently play a very minor role in CoCoALib, I am inclined to ignore BOOST exceptions (at the moment, anyway). This will allow CoCoALib to remain (largely) independent of BOOST.

BOOST exceptions do offer one tempting feature: they allow callers to add new information to exception objects as the stack unwinds.

The link in my previous post suggests that C++11 may offer a mechanism for adding info to an exception during unwinding (which may make the BOOST offering obsolete?).

The (work in progress) list of errors is now in the documentation (cvs will help us getting to the final design)
doc/txt/error.txt
(and checked it in)

--> ERROR: NOT YET IMPLEMENTED -- please be patient, we're working on it

I think it may be a cleaner design to use (impose) the convention that all exceptions CoCoALib are derived from a single class. Most exceptions report "internal" problems, but issue #714 is about an exception type for responding to external interrupts.

Does a single super-class make good sense? It would allow a user to catch any possible exception thrown by CoCoALib in a single catch statement -- I'm not sure when this might be useful...

It seems that about 2 years ago I already had the idea that all exceptions originating from CoCoALib should be derived from a single class (called CoCoA::exception). Note that if a CoCoALib function calls a function from some other library, and that function throws an exception then CoCoALib does not convert the exception to one derived from CoCoA::exception because the exception did not originate from CoCoALib.

I have had another quick look for guidance about designing exception classes, and found one page which suggested keeping KISS in mind. This seems to be good advice. So we can start with a very simple set of exception classes, and on the basis of future experiments this could perhaps be later refined.

• CoCoA::exception base class for all exceptions originating from CoCoALib
• CoCoA::error concrete class for exceptions corresponding to run-time errors
• CoCoA::InsuffPrec concrete class for twin-floats
• CoCoA::TimedOut thrown when a time-out occurs
• CoCoA::InterruptReceived concrete class thrown when an interrupt has been detected.

While it is very tempting to want to subdivide CoCoA::error into finer classes, it not at all clear to me how this could be helpful to a CoCoALib user.

• BadArg
• IncompatibleArgs
• ProgrammingError (e.g. AssertFail, ObsolescentFn, SERIOUS, NYI, iterator off end)
• other

From another point of view (kind of bottom-up).
What we have now shows a few of these situations

    DEFINE_ERROR(BadPwrZero, "Non-positive power of zero");
    DEFINE_ERROR(NotPositive, "Value is not positive");
    DEFINE_ERROR(NotPositiveGrading, "Grading must be positive");

      CoCoA_ERROR(ERR::NotPositive, "NewLexOrdering(n) size of matrix");

There are some notes about "classes of errors" in the CoCoALib documentation for error, section "=== new improved list of errors ==="
(see also issue #92 for parallel discussion)

Following on from my comment 14... well, assuming that we adopt that approach...

This means that practically all errors are represented by exceptions which are instances of a single class, CoCoA::error (or whatever name we choose). This makes the situation very similar to the current nonstandard errors, namely that essentially all the details are in the descriptive string(s).

• errors containing double negatives are confusing (e.g. "not non-negative")
• we should try to use fairly uniform messages for similar errors.

Here are some old notes about errors/exceptions I found while tidying up:

• BadArg
• IncompatibleArgs
• ProgrammingError (AssertFail, Obsolescent, ShouldNeverGetHere, NYI)
• InsuffPrec
• IntrRecd
• TimedOut

Recently I wrote some ad hoc code and wanted to use an ERR::NeverGetHere error; is this the same as SERIOUS?