commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] last steps before releasing 2.2 ?
Date Mon, 31 Jan 2011 23:14:15 GMT
Hello. :-)
Thus, you know what's coming below.

> I have shortened the message because it is now almost unreadable, so I
> would like to focus to a few points only.
> > 
> > So? If you remember, this is exactly what we talked about when we met in
> > person. "myOwnAlgorithmWhichCallsSolverAtSomeDeepLevel" is defined in your
> > application, thus *you* decide which exception it is going to throw (in this
> > case, it is "FunctionEvaluationException" which, in my view, is defined
> > somewhere in your application code). At "topLevelFunction", you *know*
> > which exception to "catch" and you do it just as your example shows.
> > I have nothing to say against this code. It is perfectly fine.
> > Just, you cannot deduce from it that "FunctionEvaluationException" must
> > exist in CM.
> I finally understood why we diverge so much (well, I hope I have
> understood). The initial problem and the reason why
> FunctionEvaluationException was there is because up to 2.1, most if not
> all of our exceptions were checked exceptions. In that case, it was
> mandatory to declare these exceptions at [math] level for users convenience.
> Now that we have switched to unchecked exceptions, this imply that we
> should force users to switch too for the code they provide to [math] in
> order to be called back.
> With a [math]-specified FunctionEvaluationException as we changed it
> (i.e. making it a subclass of MathRuntimeException), users will not see
> any change, so the change was compatible between 2.1 and 2.2, as some
> tests proved a few weeks ago.
> With a user-defined AnyProblemSpecificException that [math] knows
> nothing about, our change serves no purpose and
> FunctionEvaluationException should be removed. However, removing is an
> incompatible change so it can be done only in 3.0.
> So at the end, what remains is that the checked/unchecked change should
> be documented thoroughly (it is a BIG change and needs lots of
> explanations) and this explanation should describe this use case and
> tell users we did not forget they need exception, but we ask them to use
> their own unchecked exception for that.
> Did I get it right this time ?

100% agreement.

I must confess that now I wonder whether what might have confused you is
that all this thread was with subject "last steps before releasing 2.2 ?";
I've always targetted 3.0 when talking about the overhaul of the exceptions
usage, and never wanted to imply changing anything in this respect in 2.2.

What had started confusing me in that thread is the mixing of new and old
style exceptions, not realizing that some of the "new" in 2.2 was in fact
a temporary workaround that would be abandoned in 3.0.

Sorry if I jump-started for no reason,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message