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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
