Brent Worden wrote:
-----Original Message----- From: Phil Steitz [mailto:[EMAIL PROTECTED]
There are several approaches to design a concept for exceptions, all of which have pros and cons. I personally would suggest to avoid returning NaNs and throwing RuntimeExceptions whereever possible and use a package specific hierarchy of declared exceptions instead.
J.Pietschmann
I would agree whole-heartedly.
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.
Here's a saying I've used in the past when debating colleagues: "Just because someone else does something, that doesn't make it right." :)
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.
I am one the fence on this whole issue. I am interested in hearing more about what others may have in mind.
The big problem I have with returning NaN is the caller has little knowledge why NaN is being returned. If an exception is thrown, preferably a specialized exception like ConvergenceException, the caller knows precisely the reason for failure and can take appropriate recovery action.
I think your usage of Convergence Exception is appropriate in your case. In your case your waiting for the method to return, if it fails to converge, you need to know why, there may be different reasons, and its an "exceptional case" which probibly terminates the whole process in the long run.
But, I also supported the usage of NaN's when the result of a simple calculation falls outside the domain of "proper results" for that method. This means that log(0.0) would return a NaN, simple descriptive stats would return NaN's when the inputs were of the wrong domain.
for example, if geomean() returned a NaN in the following eq. the whole eq's return value is NaN.
MathUtils.factorial( Math.floor( Math.log( StatUtils.geomean(someobj.getArray()) )))
BUT, even again, Now that we revisit this issue, we may be wrong (and your viewpoint correct) in this respect when it comes to ease of use. If we have a generic "InvalidInputValueException", then only one exception need be caught in the process of evaluating numerious functions in a process. If all throw "InvalidInputValueException", its easily discernable where the problem arose in the calculation.
try{
MathUtils.factorial( Math.floor( Math.log(
StatUtils.geomean(someobj.getArray()) )))}catch(InvalidInputValueException iive){
iive.printStackTrace(...);
}Its a question of, is a function returning NaN an exceptional case or is it an acceptable case? And, this had/has turned into a very debatable topic.
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
