commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] deciding about 2.2
Date Fri, 04 Feb 2011 18:41:36 GMT
On 2/4/11 9:04 AM, Gilles Sadowski wrote:
> 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
>>>>>>> for 3.0. It seems to me that the switch to unchecked exceptions
>>>>>>> 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]
We need to *genuinely listen* - that means taking the feedback from
the community into account as we develop the code.  The reference
below makes no sense to me (despite the fact that I can read
French), unless it is directed at me personally, which I resent.  If
it is a general comment on community-based development, it has no
place here. 

>>>  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 point is that none of this is yet settled.  I have consistently
argued that, like ConvergenceException, FunctionEvaluationException
may be an abstraction that it makes sense for us to keep.  Just as
it is natural and useful to report that a numerical algorithm has
failed to converge, it is natural and useful to report (and be able
to recover from) a failed function evaluation.  In some (most?)
cases, that failure will be associated with a user-defined function;
in some cases not.  Therefore, MathUserException cannot in my
opinion fully *replace* FunctionEvaluationException (this is
especially clear in the signature for UnivariateRealFunction#value)

Once again, the point is that we have not settled any of this, so we
should not make commitments to users in 2.1 that we may not keep in 3.0.

>>> 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:
> For additional commands, e-mail:

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

View raw message