Project

General

Profile

Design #427

Error names and error messages (current design)

Added by Anna Maria Bigatti over 4 years ago. Updated about 1 year ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
Data Structures
Target version:
Start date:
28 Jan 2014
Due date:
% Done:

10%

Estimated time:
20.00 h
Spent time:

Description

As a sub-issue of re-designing errors here we note the suggested names.


Related issues

Related to CoCoALib - Feature #385: Design new errors using inheritanceIn Progress2013-07-08

Related to CoCoALib - Design #308: Error: ERR::NotNonZero instead of ERR::ZeroRingElem?In Progress2013-02-12

Related to CoCoALib - Feature #721: CheckForInterrupt: string arg to specify where it was called?Closed2015-05-29

Related to CoCoALib - Feature #743: Better errors: give supplementary info about the errorIn Progress2015-06-30

Related to CoCoALib - Feature #92: Error CodesIn Progress2012-02-14

Related to CoCoALib - Design #582: Error codes: use same code for "not poly ring" and "not elem poly ring"New2014-07-07

History

#1 Updated by Anna Maria Bigatti over 4 years ago

Many errors now are called Not... (e.g. NotNonZero) but that's ambiguous/confusing.
Suggestion: rename them Need... (e.g. NeedNonZero)

Joke: does that mean that NotYetImplemented should become NeedImplementing? ;-)

#2 Updated by Anna Maria Bigatti over 4 years ago

  • Target version set to CoCoALib-0.99533 Easter14

#3 Updated by John Abbott over 4 years ago

  • Target version changed from CoCoALib-0.99533 Easter14 to CoCoALib-0.99534 Seoul14

#4 Updated by John Abbott about 4 years ago

  • Target version changed from CoCoALib-0.99534 Seoul14 to CoCoALib-0.99999

#5 Updated by Redmine Admin about 3 years ago

  • Category set to Data Structures

#6 Updated by Anna Maria Bigatti over 1 year ago

  • Related to Feature #743: Better errors: give supplementary info about the error added

#7 Updated by Anna Maria Bigatti over 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?

#8 Updated by Anna Maria Bigatti over 1 year ago

#9 Updated by Anna Maria Bigatti over 1 year ago

  • Subject changed from Error names to Error names and error messages
  • Status changed from New to In Progress

#10 Updated by Anna Maria Bigatti over 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.

#11 Updated by Anna Maria Bigatti over 1 year ago

  • Related to Design #582: Error codes: use same code for "not poly ring" and "not elem poly ring" added

#12 Updated by Anna Maria Bigatti over 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.

#13 Updated by Anna Maria Bigatti over 1 year ago

  • % Done changed from 0 to 10
  • Estimated time set to 20.00 h

#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).

I think it will be useful to look at the existing error messages, and determine "subphrases" which we should use. For instance, at the moment I believe I would like to keep the following subphrases distinct:
  • 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.

#16 Updated by Anna Maria Bigatti about 1 year ago

.... just to explain what I'm doing and why: I'm doing some other things, and making mistakes (.... ehm... I'm making them on purpose ;-)
So I'm fixing the error messages I do not like as they are, trying to make them more helpful.

#17 Updated by Anna Maria Bigatti about 1 year ago

Just a trivial task (but may be annoying).
Currently in error.H we comment an error name with its string: isn't this a pointless duplication of code?

Also available in: Atom PDF