On Thu, Jan 27, 2011 at 6:14 PM, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > 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.]
I understand your point, but I disagree with it. We are back to a basic principle of API design that we need to settle. My view is that FunctionEvaluationException absolutely makes sense at the API boundary of UnivariateRealFunction#value. It is the right abstraction at that level - it says that an exception occurred evaluating a function. In some cases, for example in activating a solver, a caller will know that it is possible that an argument outside the domain of the function may be passed to the function (solving, for example, in a neighborhood that contains singularities). The caller may want to know simply that an error occurred evaluating the function. The nature of that error can be precised further by the exceptions hierarchy in one of three ways: a) narrowing the class (i.e., the actual exception may be an instance of a subclass of FunctionEvaluationException) b) unpacking a nested exception or c) examining state information or the exception message. All three of these options are available to us in designing the exceptions hierarchy and classes. I think it is naive and frankly bad design to aim to define only low-level runtime exceptions that report things like "NumberTooLarge." The principle that I stated in my earlier post that exceptions should make sense at the in the context of each API boundary means that we need a substantive hierarchy that expresses the concepts appropriate at each level. FunctionEvaluationException, like ConvergenceException, is an example of a basic concept that we need to keep, IMO. > > 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 ? > Sorry, I obviously meant "value." > 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 intent of this "misleading documentation" needs to be preserved, IMO. User-defined functions should throw MathUserException, a subclass of FunctionEvaluationExeption (new name) and the expectation should be that catching the top level class should in fact prevent things "blowing up" as a result of function activation. > >> > 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. Yes, yes, yes :) See comments above. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
