2012/2/26 Luc Maisonobe <luc.maison...@free.fr>: > Le 26/02/2012 08:47, Sébastien Brisard a écrit : >> Hi, >> I know that CM3 should be in a frozen state now, but while working >> with FieldElement this morning, I've noticed that the contract of >> divide(T) states that an ArithmeticException *should* be thrown if the >> parameter is zero. However, for this boundary case >> - BigFraction.divide(BigFraction) throws a ZeroException >> - ArithmeticException throws an ArithmeticException >> - Complex does not throw an Exception (uses NaNs) >> - Dfp, DfpDec do not throw an Exception (as far as I understand, it >> uses flags) >> - Fraction throws a MathArithmeticException. >> >> Obviously, there is a need for some cleaning up... Although it is not >> the right time. For the time being, my suggestion would be to *remove* >> from the FieldElement interface the statement that an exception must >> be thrown. The rationale for this is that sometimes, we do not want to >> throw an exception (for example, I'm using a wrapper around primitive >> double, and I want all boundary cases to be handled the same way as >> the primitive operation "/"). I do not know if this change should be >> considered as an API change. If yes, I would recommend we do it before >> releasing 3.0. Otherwise, I can do that in 3.1, together with checkng >> that when an exception is thrown, it is always of the same type. >> >> What do you think? > > +1 to remove the statement. > Done in r1293898.
Please pick the exception of your choice in MATH-755 (I would tend to favor MathArithmeticException, to remain close to e.g. BigDecimal, which throws ArithmeticException). Regards, Sébastien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
