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@GiNaC.DE> <http://www.ginac.de/~kreckel/>