commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] deciding about 2.2
Date Fri, 04 Feb 2011 12:41:47 GMT

> >>>>>> [...]
> >>>>> It seems the thread asking for help on the exception API design
is going
> >>>>> to be fruitful, and it starts well with interesting ideas. I guess
> >>>>> of these ideas will change again our view and we will converge
> >>>>> (hopefully not throwing an exception ourselves ...) to a stable
> >>>>> for 3.0. It seems to me that the switch to unchecked exceptions
> >>>>> supported by almost all participants to this thread, so this part
> >>>>> probably already stabilized.
> >>>>>
> >>>>> I doubt we can do anything about it for 2.2 and waiting first for
> >>>>> rest of the discussion to stabilize (no hierarchy/small hierarchy/large
> >>>>> hierarchy, specific getters/general context map ...) would push
2.2 too far.
> >>>>>
> >>>>> I would like to freeze 2.2 as it is now in the repository and get
it out.
> >>>>>
> >>>>> What do you think ?
> >>>>>
> >>>> +1 for getting the release out.  Given that we are not sure how things
> >>>> are going to end up in 3.0, we should remove the deprecations.
> >>> Which things? Which deprecations?
> >> The exceptions classes:  DimensionMismatchException,
> >> FunctionEvaluationException,
> >> MathException, MathRuntimeException,
> >> MaxIterationsExceededException.  Since we are still not sure what
> >> exactly we are going to do in 3.0, we should not tell users
> >> something in 2.2 and then change, so if we want to release now, we
> >> should remove these deprecations.
> > 
> > -1 for removing those deprecations.
> > 
> > Nobody gave any new argument in favour of CM having checked exceptions.
> > What exceptions we have in "trunk" cannot be qualified with the phrase
> > "large hierarchy". Nobody within CM active developers expressed a preference
> > for a "no hierarchy". We agreed on a singly rooted hierarchy (having
> > preferred it over reusing several Java standard exceptions as multiple
> > roots).
> > Nobody among the new parties to the discussion expressed anything concerning
> > the specific problem of "FunctionEvaluationException".[1]
> > The (new) issue of adding the "map" feature to the exceptions can be dealt
> > with as I proposed in a previous post.
> > Thus, unless I missed some points, I don't see anything that will  change
> > with respect to what should be removed from 2.2.
> In addition to what have already been said, the deprecations are
> basically a way to help smooth transition (if I remember well you were
> against attempts of smooth transitions) so they basically imply we know
> the direction we are heading to. Now we are not sure anymore about some
> parts.

First, I was not against trying to help if reasonably possible (such as with
deprecation marks); I was against the _delays_ implied by needlessly (IMHO)
contorted attempts.
Second, I have been told to (or, more exactly, required to) write the
deprecations for the precise reason that it is helping with the transition,
as this is a way to warn users that something is going to change. Since the
BIG change (capitalizing by you) is from "checked" to "unchecked" and, as
you say below, this is hopefully (adverb by me) going to stay, why suddenly
want to remove the early warnings? Is it OK now to not warn the users,
although we know that "MathException" is checked, that the old
"MathRuntimeException" (with its factory methods) is long-time deprecated?

> > 
> > Regards,
> > Gilles
> > 
> > [1] The consensus about this exception was to replace it with the
> >     "MathUserException" class. In my view, such a class is not more
> >     meaningful than a "FunctionEvaluationException" but since some have
> >     expressed that they would feel more comfortable with it, it was
> >     mentioned in the Javadoc (and "throws" clauses) in place of the old,
> >     checked, "FunctionEvaluationException". Now if you'd prefer to have
> >     this exception place-holder be renamed "FunctionEvaluationException",
> >     I don't oppose it, as long as it is unchecked. [Discussing this further
> >     doesn't make any sense, given that nobody can come up with a practical
> >     example showing the necessity for such an exception.
> >     I thought that the last post by Luc on this subject had reconciled the
> >     viewpoints, but either you or I must have misunderstood it.]
> The parts for which we seem to have reached consensus is the choice of
> unchecked exception, so I guess this will remain. From the paragraph
> above, it seems to me FunctionEvaluationException will finally also be
> kept (it's not certain yet, will depend on hierarchy depth), only
> changed to unchecked exception. So it's deprecation should really been
> removed and in 3.0 its base class will be changed. For now, we don't
> know what base class will be chosen.

The argument of whether "FunctionEvaluationException" will stay or not on
the basis of "hierarchy depth" is fairly brittle if one accepts that it is
such a fundamental abstraction.

> We have already delayed 2.2 too much. I know at least three projects
> that are really waiting for its release. Let's do it knowing what we
> have achieved in this version (bugs fixes, many evolutions) and what we
> have failed to do (stabilizing our exceptions). We cannot trick our
> users to think we have already chosen something when we are still
> searching for the right direction.

What do you mean by the "right direction"?  It looks like we went from a
conceptual divergence (whether the "function evaluation failure" is a
meaningful abstraction within the realm of the CM library code) to putting
everything (exception-related) we agreed on in question because of a
technical issue (i.e. the "map" functionality).
The conceptual divergence can be resolved (not by consensus, unfortunately,
but by a majority vote).
The technical issue is a non-blocking one (or please give some arguments
against my proposal suggested some posts ago).

What _exactly_ are the problems with the current code in "trunk" and why do
you refuse to give it a chance to be experimented with?
Is it just because the exceptions are grouped in an "exception" package?
Then let's put them in the top-level package if you find it more to your
taste (no matter that it will be "polluted" or that tidiness will suffer or
that we don't gain anything by doing so or that the current way makes it
easy, for users and developers alike, to locate the exceptions tailored to
their need, avoiding functionality and code duplication. It suffices that
someone says "It's bad practice", without taking into conisderation that the
CM code base is probably fairly larger and its functionality is more diverse
than any other Commons "component"...).
Or is it that you seriously consider going back to the old ways of conveying
the failure info through messages only, within a unique "MathException".
Well, this must surely be "standard" practice for a strongly typed

> So +1 to remove these deprecations.

Does that mean that you will want a 2.3 release?


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

View raw message