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 14:04:26 GMT
On Thu, Feb 03, 2011 at 08:15:29PM -0500, Phil Steitz wrote:
> On 2/3/11 7:18 PM, Gilles Sadowski wrote:
> > On Thu, Feb 03, 2011 at 06:11:19PM -0500, Phil Steitz wrote:
> >> On 2/3/11 5:02 PM, Gilles Sadowski wrote:
> >>>>>> [...]
> >>>>> 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
> We are one community here in Commons.  We have asked the community
> for input.  We need to listen to it.

Do we have to obey every and all suggestions?
Taking the "community" argument for one-sided use is akin to a famous
joke on "communism".[1]

> >  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]
> I do not agree with the "consensus" to replace
> FunctionEvaluationException.  It may end up one of the concepts we
> want to keep.  As I have stated elsewhere, it cannot be replaced
> fully by MathUserException.

If you listen to some of the suggestions, it can:

Solution (1):
  throw new MathUserException("Failed to evaluate at " + x);

Solution (2)
  MathUserException e = new MathUserException("Failed to evaluate");
  e.add("argument", x);
  throw e;

The points, made in the suggestions, were that specifc exceptions may not be
necessary, that a single exception with an English language message may be

The point I make is that, if we consider squeezing the exception hierarchy
(a bad idea IMO), it would make even more sense to not have a dedicated
"FunctionEvaluationException". In such a context, there nothing inherently
wrong in reusing a "MathUserException" when some CM statement indeed "uses"
the "UnivariateRealFunction" interface (i.e. CM is a user of itself).

> > 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.
> >
> Several people have pointed out that is may be a bad practice to
> lump exceptions into an exceptions package.

I've presented a few arguments in answer to that opinion; still waiting
counter-arguments (as in "Why is it a bad practice?"). [I know a few
drawbacks myself, but they are balanced by the advantages.]

While I should abide by this pre-conceived statement (which might be
perfectly valid for some other "components", just not as clear-cut for
CM), isn't it strange that you don't "listen" to people who say that
message localization is a mistake?

>  Some of the
> deprecations are related to that.

Then make the deprecation less explicit concerning the location of the
replacements; that doesn't imply that the deprecations are not in order.


[1] [Not sure how it is translated in English:]
    Ce qui est à toi est à moi; ce qui est à moi, n'y touche pas!

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

View raw message