commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [math] deciding about 2.2
Date Fri, 04 Feb 2011 01:41:14 GMT
On 4 February 2011 01:15, Phil Steitz <phil.steitz@gmail.com> 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.
>>  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.
>> 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.  Some of the
> deprecations are related to that.  If we want to push out 2.2 before
> we decide how things are going to be structured moving forward, we
> need to remove the deprecations.

+1 to removing these deprecations.

> Phil
>> Regards,
>> Gilles
>>
>> [1] The consensus about this exception was to replace it with the
>>     "MathUserException" class. In my view, such a class is not more
>>     meaningful than a "FunctionEvaluationException" but since some have
>>     expressed that they would feel more comfortable with it, it was
>>     mentioned in the Javadoc (and "throws" clauses) in place of the old,
>>     checked, "FunctionEvaluationException". Now if you'd prefer to have
>>     this exception place-holder be renamed "FunctionEvaluationException",
>>     I don't oppose it, as long as it is unchecked. [Discussing this further
>>     doesn't make any sense, given that nobody can come up with a practical
>>     example showing the necessity for such an exception.
>>     I thought that the last post by Luc on this subject had reconciled the
>>     viewpoints, but either you or I must have misunderstood it.]
>>
>> ---------------------------------------------------------------------
>> 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
>
>

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


Mime
View raw message