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