> [...]
> >
> >In the above, there is also a hidden request: I would like to remove the
> >checked "FunctionEvaluationException" from the interface. As mentioned
> >recently in a [VFS] thread, the only argument in favor of checked
> >exceptions
> >is in situations where the code really implements local retries.
> >What would
> >you retry here? [If the answer is "Another value for the parameter
> >x", that
> >would just mean that we should instead throw an "IllegalArgumentException"
> >for the x that lead to failure.]
> >This will hugely simplify user (and CM) code.
> >I will create a new (unchecked) "FunctionEvaluationException" in package
> >"exception" so that current users of the exception would just have to do a
> >global search and replace:
> >
>
> I'm -0 on having it unchecked. But as long as it is documented in
> the javadocs, I don't have a problem. Unlike {VFS}, it is more
> likely that [math] users want to catch and handle something like
> sqrt(-1). I'd be -1 to removing the exception all together, since
> it is a major pain to try and figure out why you got a NaN value
> when debugging your code.
Indeed, which unchecked exception to throw is a question of policy (as
opposed to the compiler-enforced "throws" clause), to be documented.
Your example stresses the problem that "FunctionEvaluationException" is not
the best choice because -1 is an illegal argument for "sqrt". Hence, for
a "Sqrt" function object, the standard policy would mandate to throw a
subclass of "IllegalArgumentException", which conflicts with the _a-priori_
choice of a checked exception.
The suggested CM policy would thus be that implementations of
"UnivariateRealFunction" must throw an "IllegalNumberException" when the
argument is not valid for that function.
I proposed to create a new, unchecked, "FunctionEvaluationException" in
order to ease the transition of codes using CM but, in principle, I don't
see it as really useful. It could be, if CM wants to be really verbose:
Any CM code that calls a user-defined function can catch all
"RuntimeException"s that could arise from this unknown code and then wrap
it inside the new "FunctionEvaluationException" with some additional info.
[Note that this completely different from the assumed usage of the current
"FunctionEvaluationException": Force functions to throw it although CM never
handles it!]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
