Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Date: Fri, 4 Feb 2011 15:04:26 +0100
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] deciding about 2.2
Message-ID: <20110204140426.GA22814@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: <4D47560E.3000703@gmail.com>
 <ii9fgh$lik$1@dough.gmane.org>
 <4D4859BC.5020301@free.fr>
 <4D48E387.8020304@gmail.com>
 <4D4922AA.8020900@free.fr>
 <AANLkTinna+g-MYZxmVpggVoH_qw5tK+aTsaeyXKsgPY8@mail.gmail.com>
 <20110203220231.GF22170@dusk.harfang.homelinux.org>
 <4D4B3617.30405@gmail.com>
 <20110204001802.GG22170@dusk.harfang.homelinux.org>
 <4D4B5331.4020905@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4D4B5331.4020905@gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)

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 some
> >>>>> of these ideas will change again our view and we will converge
> >>>>> (hopefully not throwing an exception ourselves ...) to a stable design
> >>>>> for 3.0. It seems to me that the switch to unchecked exceptions is
> >>>>> supported by almost all participants to this thread, so this part is
> >>>>> probably already stabilized.
> >>>>>
> >>>>> I doubt we can do anything about it for 2.2 and waiting first for the
> >>>>> 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
sufficient.

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.


Gilles

[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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org