Richard B. Kreckel
kreckel at thep.physik.uni-mainz.de
Thu Oct 3 13:10:16 CEST 2002
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
> Why is there such a difference?
Probably because nobody has really check carefully for the exception
> 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.
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>
More information about the GiNaC-list