Project

General

Profile

Design #1063

Catching an (expected) error

Added by Anna Maria Bigatti almost 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Anna Maria Bigatti
Category:
Documentation
Target version:
CoCoALib-0.99560
Start date:
09 May 2017
Due date:
% Done:

100%

Estimated time:
Spent time:
1.55 h

Description

Decide how to catch and expected error, for example a "Cannot reconstruct rational"

Related issues

Related to CoCoA-5 - Bug #1062: IsRadical bug?Closed2017-05-09

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

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

History

#1 Updated by Anna Maria Bigatti almost 7 years ago

  • Category set to Documentation
  • Target version set to CoCoALib-1.0
  • % Done changed from 0 to 10

I had some trouble deciding how to catch an error:
I was expecting a possible problem in applying a partial hom, and I did not want to write explicitly the message string.
I wrote it this way, but I do not like it much.

    catch (const CoCoA::ErrorInfo& e)
    {
      if (message(e) == message(ErrorInfo(ERR::BadRingHomArg2,"")))
      {
        VERBOSE(80) << "   UGLY PRIME: going to next prime" << std::endl;
        continue;
      }
      throw;
    }

Is there a better way than creating an ErrorInfo to compare the errors.
Maybe yes, but I didn't find it. I keep searching: if I find it I'll write it here ;-)

#2 Updated by Anna Maria Bigatti almost 7 years ago

  • Status changed from New to Feedback
  • Assignee set to Anna Maria Bigatti
  • Target version changed from CoCoALib-1.0 to CoCoALib-0.99560
  • % Done changed from 10 to 90

Found it (I had been confused by another unexpected error).
Easy: BTW I changed name to the error

    catch (const CoCoA::ErrorInfo& err)
    {
      if (err == ERR::BadPartialRingHomArg)
      {
        VERBOSE(80) << "   UGLY PRIME: going to next prime" << std::endl;
        continue;
      }
      throw;
    }

#3 Updated by Anna Maria Bigatti almost 7 years ago

#4 Updated by Anna Maria Bigatti almost 7 years ago

#5 Updated by John Abbott almost 7 years ago

  • Related to Feature #385: Design new errors using inheritance added

#6 Updated by John Abbott almost 7 years ago

I am a bit uneasy about using the following paradigm more than absolutely necessary:

try
{
  ans = SomeComputation(args);
}
catch (const CoCoA::ErrorInfo& err)
{
  if (err != ExpectedError) throw;
  // ignore expected error
}

We do use this approach for InsuffPrec with twin floats (since there is no reasonable alternative).
In the cases Anna has mentioned (here on redmine) in the last few days, I am less convinced that there is no reasonable alternative.

#7 Updated by John Abbott over 6 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 90 to 100

Also available in: Atom PDF