On Thu, Jan 27, 2011 at 08:31:05PM +0100, Luc Maisonobe wrote:
> Le 27/01/2011 17:49, Phil Steitz a écrit :
> > On Thu, Jan 27, 2011 at 9:20 AM, Gilles Sadowski
> > <gil...@harfang.homelinux.org> wrote:
> >> Phil,
> >>
> >>> OK. But now that we have detected an "aroma" around unilaterally
> >>> making UnivariateRealFunction throw Math*User*Exception, I wonder if
> >>> there is a way to introduce an unchecked parent that gets us out of
> >>> this. We may want to reserve the right to do this in 3.0, so the "head
> >>> start" in 2.2 might be a head start to nowhere, unless we find a way
> >>> to fix it in 2.2 (or you convince us that the current setup is an OK
> >>> long-term solution).
> >>
> >> I don't understand what you mean.
> >> "MathUserException" is unchecked so it has no consequence that it is in a
> >> "throws" clause.
> >> Or do you want to not remove FunctionEvaluationException from the "throws"
> >> clause (because it is not a backward-compatible change)?
> >>
> > The "aroma" I was referring to is that MathUserException is not,
> > strictly speaking a suitable replacement for
> > FunctionEvaluationException. The intent as described in the javadoc
> > for MathUserException is that it allows exceptions in user-defined
> > functions to be propagated through [math] API layers (an excellent
> > idea, IMO).
I somewhat agreed on this point, because it doesn't hurt, although, as said
earlier, I really doubt that we can set a standard. [Anyway IMO it's fine
that users create whatever exception they like.]
> > The problem is that FunctionEvaluationException is
> > broader - it could apply to non-user-defined functions, as in the
> > interpolation code that Luc pointed out.
I mentioned that the "interpolate" method creates an object that implements
the "UnivariateRealFunction" interface.
Unless I'm missing something, the "problem" you mention does not exist. The
actual problem was the very _existence_ of "FunctionEvaluationException": A
class that was almost never actually instantiated within CM (and in the
places where it was, it was the wrong thing to do). [And the fact that is
was a chacked exception made things worse: try/catch all the way up for
something that never happens! That's why I argued that it be removed.]
Back to the issue of the interpolators: When an interpolator implementation
encounters a problem, it must throw a specific exception that represents
that problem; it might be e.g. an "OutOfRangeException" (because the user is
trying to extrapolate) but it doesn't mean that "OutOfRangeException" must
be a subclass of a "FunctionEvaluationException" or even a subclass of an
"InterpolationException" (because, as a problem description,
"OutOfRangeException" is unrelated to those). These supposedly high-level
exception don't bring any new information to CM; they are empty shells.
> > Making it the exception
> > thrown by UnivariateRealFunction#solve de facto limits the scope of
> > UnivariateRealFunction to user-defined functions.
I don't get this. What is UnivariateRealFunction#solve ?
Anyways, (guessing from the last part of the sentence)
"UnivariateRealFunction" is certainly not limited to user-defined functions.
Implementations (within CM and outside it) can throw *any* kind of unchecked
exception. [It's just that, as I had also pointed out, the documentation is
misleading for the unwary user (who might think that catching
"MathUserException" will prevent any blow-up).]
> > The current 2_x
> > code cleverly replaces FunctionEvaluationException but still allows
> > user functions to throw it and user code to catch and handle it. The
> > problem is that it replaces it uniformly within [math] with
> > MathUserException. What might be better would be to replace
> > MathUserException with something like FunctionEvaluationException
> > (oops - that name is taken - need something else) and then have the
> > current MathUserException be a subclass, reserved for user functions.
> > Most internal signatures would then reference
> > FunctionEvaluationException2 (just kidding about the name, need
> > something else), but user functions would throw MathUserException.
>
> This seems a good idea to me, and I don't have ideas for a name of the
> higher level exception.
No, no, no.
In "trunk", there are only 4 instances where a "MathUserException" is
actually instantiated. In 3 of them, it is used to wrap a checked exception;
before the release of 3.0, these exceptions will be replaced by new ones,
unchecked and specific. The last occurrence is
---
if (Double.isNaN(ret)) {
throw new
MathUserException(LocalizedFormats.CUMULATIVE_PROBABILITY_RETURNED_NAN, x, p);
}
---
In this case, it should be replaced either by a "NotFiniteNumberException"
or by something more elaborate like "IterateRangeException" (?) as proposed
by Phil.
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
