commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject [math] deciding about 2.2 (was Re: [all][math] Help wanted with exceptions API design)
Date Wed, 02 Feb 2011 09:23:54 GMT
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 ?


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

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

View raw message