[Math] FunctionEvaluationException in UnivariateRealFunction (Was: Re: svn commit: r1030464 [1/3] - ...)

[Gilles Sadowski <gi...@harfang.homelinux.org>]

Hi.

> > [...]
> > > 
> > > 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.


There are at least 2 different issues:
1. What is the recommended behaviour of implementations
2. What CM will do when it calls "value" and catches an exception

For (1) I don't think that it is wise to suggest that any function should
throw "FunctionEvaluationException", because this exception doesn't convey
any information. For example, a function that will compute the square-root
should better throw a more specific "NotPositiveException" (a subclass of
"IllegalArgumentException") when passed a negative argument.

If some part of CM wants to catch a failure (e.g. because the computation
can meaningfully continue, or just to provide a localized message), it is
certainly not safe to catch only "FunctionEvaluationException" since indeed
we cannot enforce that it will be the only exception type to arise.
Hence, for (2), we will catch *any* "RuntimeException" (and continue, or
throw a "FunctionEvaluationException").
It is thus useless and misleading to recommend something that we don't care
about.

Thus, neither (1) nor (2) is reason for letting appear the word
"FunctionEvaluationException" within the interface file.

To summarize, a "FunctionEvaluationException" class only makes sense, IMHO,
for the localization (of exception messages) requirement: Catch every
exception and wrap it in a "FunctionEvaluationException".
[If you agree with this use-case, I'll modify the new
"FunctionEvaluationException" so that it takes the cause as its argument.]

Please let me know whether you have use cases that would contradict the
above.

> > [...]

Best, ;-)
Gilles

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