commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [all][math] Help wanted with exceptions API design
Date Wed, 02 Feb 2011 07:53:00 GMT
Why are the messages not externalized in a properties file?


On Feb 1, 2011, at 23:55, "Phil Steitz" <> wrote:

> 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.
> Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message