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). The problem is that FunctionEvaluationException is > broader - it could apply to non-user-defined functions, as in the > interpolation code that Luc pointed out. Making it the exception > thrown by UnivariateRealFunction#solve de facto limits the scope of > UnivariateRealFunction to user-defined functions. 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. Luc > > Phil >> >> Gilles >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
