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 01:15:29 GMT
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.

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


Mime
View raw message