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 (was Re: [all][math] Help wanted with exceptions API design)
Date Thu, 03 Feb 2011 16:43:58 GMT
On Wed, Feb 2, 2011 at 4:23 AM, Luc Maisonobe <> wrote:
> Le 02/02/2011 05:54, Phil Steitz a écrit :
>> On 2/1/11 2:06 PM, Luc Maisonobe wrote:
>>> Le 01/02/2011 18:22, Jörg Schaible a écrit :
>>>> Hi,
>>>> Phil Steitz wrote:
>>>>> We are in process of redesigning our exceptions hierarchy in [math]
>>>>> and we could use some input / perspective from other Commons
>>>>> community members.  Thanks in advance for your feedback and perspective.
>>>>> The most recent attempt at agreeing on design principles is [1] and
>>>>> I have tried to document the points of agreement in a section that I
>>>>> just added to the [math] Developer's Guide [2] (it will take a few
>>>>> hours for this to make it to the live site.  The source xdoc is in
>>>>> trunk/src/site/xdoc/developers.xml)
>>>>> The JIRA issue [3] referenced in [1] calls out a specific point on
>>>>> which we are trying to gain consensus in a specific example.
>>>>> The currently defined exceptions in [math] can be found in the
>>>>> top-level package and .exceptions.  Those in the top-level have at
>>>>> this point been deprecated.
>>>> Has anyone of you considered the usage of an exception context? We introduce
>>>> this with lang3 (
>>>> beta/org/apache/commons/lang3/exception/ExceptionContext.html) and it
>>>> basically adds a map with key/value pairs to the exception itself.
>>>> This concept has worked out quite nicely especially in situations where code
>>>> can nest deeply in conjunction with user-provided code that make calls in
>>>> the core functionality again.
>>>> The nice part is that you can add information at each position that can
>>>> provide useful information (assuming MathException implements this
>>>> interface):
>>> We didn't consider that :-(
>>> It seems very interesting to me.
>>> What do other think about it ?
>> Thanks,  Jörg!
>> Very nice idea.  I can see added value implementing the interface;
>> but unfortunately I don't see it replacing either the localization /
>> message framework or the hierarchy.   For reasons that others have
>> stated, I think that we do need a simple hierarchy.   We also need
>> messages that convey more than data values and I am concerned that
>> making sense out of key/value pairs in messages would require
>> brittle convention-maintaining.  Have a look at the messages that we
>> maintain today:
>> It could be, though, that the embedded machinery might be useful and
>> allowing users to add data to exception messages is a powerful feature.
> 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.


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

View raw message