commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: svn commit: r1030464 [1/3] - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/ main/java/org/apache/commons/math/analysis/ main/java/org/apache/commons/math/analysis/integration/ main/java/org/apache/commons/math/analysis/inte
Date Thu, 04 Nov 2010 22:53:00 GMT
> >> IMHO we still need the @throws line in the javadoc.  Otherwise end
> >> users are going to get a nasty surprise when they get an unchecked
> >> exception thrown.
> >>
> >
> > Any existing user code (throwing a "FunctionEvaluationException" at some
> > point and catching it at another) will still work the same as before
> > (provided they change the "import" statement). No surprise to be expected.
> >
> >
> > Best,
> > Gilles
> >
> What about new code?  With the current signature and documentation
> there is no information on possible exception conditions.  The fact
> the method will throw an exception on failure needs to be expressed.
> [...]

The fact is: You don't know whether an exception will be raised on failure.
It depends on the implementation: A user might decide that failure is
dealt with by returning "NaN" (or Infinity).
Another user might decide to throw a "MathIllegalArgumentException" or a
subclass thereof or something completely different... :-)
IMHO, the "FunctionEvaluationException" is fairly useless. Its only use I
can see is to wrap "alien" (user-defined) exceptions: Any methods in CM
could call "value" within a try/catch block, catch any "RuntimeException"
and rethrow it wrapped inside our own "FunctionEvaluationException" such
that it can always print a localized message. [Note that in this case, it
is not the "value" method that throws "FunctionEvaluationException" but the
code that calls "value".]


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message