commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <j3322...@yahoo.de>
Subject Re: [math] proposed ordering for task list, scope of initial release
Date Wed, 11 Jun 2003 20:33:59 GMT
Phil Steitz wrote:
> That's where I started, but then Tim and others convinced me that it was 
> actually better/more convenient for users for us to behave more like 
> java.Math and java's own arithmetic functions -- which use NaN all over 
> the place.

Uh, oh. That's probably because of IEEE 854 does so. Returning
NaNs as well as throwing RuntimeExceptions is appropriate if
checking for problems would unnecessarily clutter the whole
program code, in particular if the exceptional conditions can
potentially occure often in a small amount of source code while
in reality occuring rerely. I mean, You certainly don't want to
declare an ArrayOutOfBoundsException just because you want to
make an array access, in particular if the index has already
been checked elswhere for other reasons.
Keep also in mind that NaNs had been invended before high level
languages generally aquired reasonable mechanisms for handling
exceptions, and that this means the hardware is designed to deal
with NaNs rather than throwing exceptions. Java probably adopted
NaNs mainly because checking every FP operation for a NaN would
have been an utter performance killer.

The question is: can the user be expected to provide more often
valid input to commons-math methods than not? If so, will checking
for a math exception clutter the user's routines too much?

>  Also, from a usage standpoint, if we use checked exceptions 
> everywhere, this is a bit inconvenient for users.  We need to find the 
> right balance.
Exactly.

It is, however, common for libraries to use checked exceptions.

J.Pietschmann


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


Mime
View raw message