commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc.maison...@free.fr
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 Fri, 05 Nov 2010 00:01:14 GMT
Hi Gill,

----- "Gilles Sadowski" <gilles@harfang.homelinux.org> a écrit :

> > >> 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

When this exception was unchecked, it was the primary use of it : wrapping
exceptions unknown to [math]. Of course, we cannot enforce users to use it
and even when it was checked users could decide to throw any other unchecked
exceptions or return NaN. Documenting it is simply a gentle way to tell our
users this exception is the recommended way to signal errors.

best regards,
Luc

> 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".]
> 
> 
> Best,
> Gilles
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org

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


Mime
View raw message