Feature #385
Design new errors using inheritance
Description
So that C++'s try...catch
mechanism can be used easily we should redesign CoCoALib's error codes so that they are in an inheritance hierarchy.
- allow programmers to catch certain exceptions and handle them;
- produce helpful(?!) error messages if not caught & handled
We have little experience with the first use.
Related issues
History
#1 Updated by John Abbott almost 11 years ago
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!
#2 Updated by John Abbott almost 11 years ago
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).
#3 Updated by John Abbott almost 11 years ago
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?).
#4 Updated by John Abbott almost 11 years ago
- Assignee set to John Abbott
- % Done changed from 0 to 30
- we are too ignorant about catching/handling exceptions to make a good design decision
- it is very hard to subdivide errors/exceptions "unanimously" into classes
- we could not think of any convincing scenarios to inspire us
- the number of different errors must be greatly reduced (there are several "duplicates")
#5 Updated by Anna Maria Bigatti almost 11 years ago
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)
#6 Updated by Anna Maria Bigatti over 10 years ago
- Target version set to CoCoALib-0.99533 Easter14
#7 Updated by John Abbott about 10 years ago
- Status changed from New to In Progress
- Target version changed from CoCoALib-0.99533 Easter14 to CoCoALib-1.0
#8 Updated by Anna Maria Bigatti about 9 years ago
--> ERROR: NOT YET IMPLEMENTED -- please be patient, we're working on it
This is pretty useless for a CoCoA-5 user (and then for us, debugging) because by default CoCoA-5 does not print the whole error report.
It would be nice to throw it like
(a)
CoCoA_ERROR(ERR::NYI + "multivariate polynomial", FunctionName);
or
(b) @CoCoA_ERROR(ERR::NYI ("multivariate polynomial"), FunctionName);@
#9 Updated by John Abbott about 9 years ago
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...
#10 Updated by John Abbott about 9 years ago
- % Done changed from 30 to 40
JAA has now implemented a simple superclass CoCoA::exception
from which all exceptions which CocoALib could throw must be derived.
Implemented, documented, (mildly) tested, checked in. The design "feels right".
#11 Updated by Anna Maria Bigatti over 8 years ago
- Target version changed from CoCoALib-1.0 to CoCoALib-0.99550 spring 2017
#12 Updated by John Abbott almost 8 years ago
- Target version changed from CoCoALib-0.99550 spring 2017 to CoCoALib-0.99560
#13 Updated by Anna Maria Bigatti about 7 years ago
- Related to Feature #1045: Error message from cocoalib to cocoa-5 added
#14 Updated by John Abbott about 7 years ago
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.
My current thoughts are the following:CoCoA::exception
base class for all exceptions originating from CoCoALibCoCoA::error
concrete class for exceptions corresponding to run-time errorsCoCoA::InsuffPrec
concrete class for twin-floatsCoCoA::TimedOut
thrown when a time-out occursCoCoA::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.
CoCoA::error
here are some possible subclasses:
BadArg
IncompatibleArgs
ProgrammingError
(e.g.AssertFail
,ObsolescentFn
,SERIOUS
,NYI
, iterator off end)other
#15 Updated by Anna Maria Bigatti about 7 years ago
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");
called, for example by
NewLexOrdering
. As it is already done in some functions, we could have just one "MustBePositive" and extra information (if necessary!) in the second argument:CoCoA_ERROR(ERR::NotPositive, "NewLexOrdering(n) size of matrix");
#16 Updated by Anna Maria Bigatti about 7 years ago
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)
#17 Updated by John Abbott about 7 years ago
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.
#18 Updated by John Abbott about 7 years ago
- Related to Design #1063: Catching an (expected) error added
#19 Updated by John Abbott almost 7 years ago
- Related to Bug #1095: TimeOut not working as hoped/expected added
#20 Updated by John Abbott almost 7 years ago
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?
#21 Updated by John Abbott almost 7 years ago
- Related to Design #1098: Ctors for exceptions/errors added
#22 Updated by John Abbott over 6 years ago
- Target version changed from CoCoALib-0.99560 to CoCoALib-0.99600
#23 Updated by John Abbott about 6 years ago
- Target version changed from CoCoALib-0.99600 to CoCoALib-0.99650 November 2019
#24 Updated by John Abbott about 5 years ago
- Priority changed from Normal to Urgent
- Target version changed from CoCoALib-0.99650 November 2019 to CoCoALib-0.99700
This really the same as #743.
#25 Updated by John Abbott over 4 years ago
- Target version changed from CoCoALib-0.99700 to CoCoALib-0.99800
#26 Updated by John Abbott about 4 years ago
- Related to Design #1462: Change CoCoA_ERROR into CoCoA_THROW_ERROR added
#27 Updated by John Abbott over 3 years ago
- Target version changed from CoCoALib-0.99800 to CoCoALib-0.99850
#28 Updated by John Abbott 5 months ago
- Target version changed from CoCoALib-0.99850 to CoCoALib-0.99900
#29 Updated by John Abbott 3 months ago
- Related to Design #1807: Error codes: "Not..." for "blah must be ..." -- change prefix added
#30 Updated by John Abbott 5 days ago
Has this been urgent for the past 11 years? Oops!
#31 Updated by John Abbott 5 days ago
- % Done changed from 40 to 50
I have just read through all the comments above. The suggestion in comment 14 looks to be a very good start -- I cannot right now think of a better design.
The cases InsuffPrec
, TimedOut
and InterruptReceived
are different from normal errors. The first are "expectable" exceptions, and the third comes from user interaction. I say we go with this design together with an extra field for supplementary information as suggest in issue #743.