On 4 February 2011 01:15, Phil Steitz <phil.ste...@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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
