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? Sébastien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
