Exceptions.

[Richard B. Kreckel]

Hi,

On Thu, 3 Oct 2002, Tatiana Zolo wrote:
> I have problems in understanding GiNaC policy regarding the choice of
> exceptions thrown.
>
> The operator `operator/' defined on objects of the class `numeric'
> throws a `runtime_error' in the case of a division by zero. In contrast,
> the `operator/' defined on objects of the class `ex' throws a
> `logic_error' in the case of a division by zero.

Not exactly.  They throw a pole_error with a specified pole degree.
pole_error is derived from domain_error, which in turn is derived from
logic_error.

> Why is there such a difference?

Probably because nobody has really check carefully for the exception
scheme.

> According to the standard, the exception `logic_error' should be used
> when errors could have been detected before program execution: I thus
> believe that a `runtime_error' should be thrown even in the case of an
> `ex' object.

Citing Stroustrup TC++PL3, section 14.10 "Standard Exceptions":

    "Logic errors are errors that in principle could be caught either
    before the program starts executing or by tests of arguments to
    functions and constructors.  Run-time errors are all other errors.
    Some people view this as a useful framework for all errors and
    exceptions; I don't."

Mathematically speaking, a division by zero is a domain error, isn't it?
On the other hand, I agree that it shouldn't be a logic error.  So, now
I'm confused.  Or is it an overflow_error?  Hmm, maybe pole_error should
be derived from runtime_error???

Note also that the degree of divergence (is it 1/x or 1/x^2) can be
potentially useful for lifting singularities.  However, I am not aware
that it is actually being used somewhere at present.

> The same argument hold for the exception thrown by `power':
>             logic_error: power::eval(): division by zero.

This is to be expected since operator/(ex&a,ex&b) just constructs a
power(b,-1) and then let's mul::eval() do the job.

If you have a day to think about it, please check all division by zero
exceptions thrown by GiNaC and do suggest a more consistent scheme.

Regards
    -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>
<http://www.ginac.de/~kreckel/>