commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <sebastien.bris...@m4x.org>
Subject [math] On the contract of FieldElement<T>.divide(T)
Date Sun, 26 Feb 2012 07:47:14 GMT
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message