commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [all][math] Help wanted with exceptions API design
Date Wed, 02 Feb 2011 04:54:31 GMT
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.


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

View raw message