CoCoA » CoCoALib

John Abbott wrote:

I agree that BadArg is unhelpful. It would be nice to settle this matter, and it would be nice to find some guidelines on how to design error hierarchies... Something to do over the easter weekend?
Priority increased.

I don't think we can fix this before next (imminent) release.

I wonder if it could be helpful to have BadArg1 and BadArg2, so that there is some indication of which arg is causing the trouble? I can see that this might also be misleading in some cases.

dangerous: some function may be called cascading from CoCoA-5 (see also just below)

One thing we should probably change is that CoCoA-5 should print more than just the main error message. Example:

 
      if (N <= 0) CoCoA_ERROR(ERR::BadArg, "LucasTest(N):  N must be positive");

So, either we decide that the second argument has a different use (==> passed to CoCoA-5), of the information "N must be positive" should be part of the first argument.

Maybe the function name (i.e. second argument) should indeed be passed to CoCoA-5 toghether with the error message (i.e. first argument), whereas the other details (file name, line number)

On the line of what I said earlier, I implemented in Interpreter.C the function MESSAGE(err) to be called instead of message(err).
It just prints message + context. Have a try and see how it looks (cvs-ed).

May be improved, and is not THE solution to this issue, but it is a quick solution to the problem of unhelpful error messages in CoCoA-5.

I agree that resolving this issue will take more time than we can invest in the next release.

I think it would be helpful to collect some examples where the current error response is distinctly unhelpful.

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)

Anna suggests that the error message should also indicate which args (via their indices, starting from 0 or 1?)
For instance in FloatApprox the err mesg should be something like arg 2, relative error must be between 0 and 1

I suppose "2nd arg" is probably clearer than "arg 2"...?

We agreed that the string for the name of the function should contain just the name of the function, and its arguments.
So we could have

  if (N <= 0) CoCoA_ERROR(ERR::MustBePositive, "N", "LucasTest(N)");

for example, this would be nice

/**/  EulerTotient(-100);
--> ERROR: arg N must be strictly positive
--> [CoCoALib] EulerTotient(N)
--> /**/  EulerTotient(-100);
-->       ^^^^^^^^^^^^^^^^^^

Let's finish this for version 1.0