commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
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
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]
>
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. 

Phil
>>>  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.

Phil
>>> 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
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message