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

Reply via email to