Error names and error messages (current design)
As a sub-issue of re-designing errors here we note the suggested names.
#7 Updated by Anna Maria Bigatti about 1 year ago
Anna Maria Bigatti wrote:
Many errors now are called Not... (e.g. NotNonZero) but that's ambiguous/confusing.
Suggestion: rename them Need... (e.g. NeedNonZero)
I'm quite keen to change the names (I'm confused myself in the meaning of the negation)
NeedNonZero or MustBeNonZero?
#10 Updated by Anna Maria Bigatti about 1 year ago
In the error messages there are some "is not" and some "must be"
DEFINE_ERROR(NotPositive, "Value is not positive"); DEFINE_ERROR(NotPositiveGrading, "Grading must be positive");
I prefer must be in the text.
Similarly, I prefer MustBe or Need in the name, instead of Not.
#12 Updated by Anna Maria Bigatti about 1 year ago
- Subject changed from Error names and error messages to Error names and error messages (current design)
I think that, while thinking of the design using inheritance, it would help to simplify the current design. If we decide that the second argument of the error (the name of the function) could also give some extra indication, i.e. which argument is bad, than we could unify some errors. This is a step towards a classification.
I'll list here some proposals, and wait for John's approval.
BadIndex, BadRowIndex, BadColIndex, BadDegIndex, BadComptIndex,...
They are all Index out of range. I would make just IndexOutOfRange, and make sure the second argument of the error gives sufficient information to understand the case.
Indeed I'd rather have the two cases NeedNonNegative/ArgTooBig, but I prefer going in steps: this is a big change in the organization.
#14 Updated by John Abbott about 1 year ago
My current thoughts abou the design of errors is that CoCoALib errors will be represented as instances of very few distinct classes -- right now, I am thinking of just a single class (see #385).
If my current ideas come to fruition then essentially all details about the error will have to be in the string, but I would like the strings for different messages to be fairly uniform e.g. where appropriate we always write
must be positive, rather than using other variants with much the same meaning (such as
should be positive,
expected positive, and so on).
out of range
must be positive
must be non-negative
They do all convey the idea of being "out of range", but I think it may be kinder to the user to have a "positive"/"non-negative" message -- that those messages give an indication about which range is valid!
#15 Updated by Anna Maria Bigatti about 1 year ago
I simplified a few error messages and clarified error for
PolyRingHom. Excerpt (
const std::string FnName = "PolyRingHom(Rx,S,CoeffHom,IndetImages)"; (...) if (codomain(CoeffHom) != S) CoCoA_ERROR(ERR::BadCodomain, FnName + ": argument CoeffHom"); if (NumIndets(Rx) != len(IndetImages)) CoCoA_ERROR(ERR::BadArraySize, FnName + ": arguments Rx, IndetImages");
This is a bit like what we have in CoCoA-5, where the faulty argument is underline.
I'm not changing the names now (good names are for developers, good messages are for the users! ... and the developers ;-). Anyway BadArraySize should be IncompArraySize.