commons-dev mailing list archives

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

They are externalized in a properties file: <>

They enum Phil pointed out here: >> defines a
default English message in case a message is not translated in a
specific language (i.e. all but French) and the translations are in
properties files. This change has been introduced in June 2010, so it
will be first published with the upcoming 2.2.


> Gary
> 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:

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

View raw message