On Sun, Feb 26, 2012 at 11:12:03AM +0100, Luc Maisonobe wrote:
> 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.

Sébastien (and others),

Please do whatever "easy" changes you deem necessary.[1]
It'll require several "build" commands until I correctly complete all the
steps toward a release; so, no problem at the moment.
Once I can achieve the process in one go, I'll let you know.


Best regards,
Gilles

[1] Thus, please, do not embark on modifications that would require work
    that spans several days...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to