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