commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [all][math] Help wanted with exceptions API design
Date Wed, 02 Feb 2011 07:46:17 GMT
Hi Gilles,

Gilles Sadowski wrote:

>> > [...]
>> > 
>> > 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 ?
> I'm not so enthusiastic: Right now I don't see how it will improve the
> current situation in CM. An example might help me understand the
> advantages. However I'm not really happy with the current localization
> scheme, so I would not be against trying something else if it can be
> improve that way.
> [One nice thing might be that we would not be limited to one "general" and
> one "specific" problem description.
> One not so nice thing is that we wouldn't have different exception types,
> each with a specific interface.]
>> > [...]
>> > 
>> > ... and remember, you can add the context interface to various
>> > exceptions, you don't have to maintain a hierarchy.
>> > ... and your users can add values also that are interesting e.g. for
>> > their stop condition without wrapping or inventing new exceptions.
> Do I understand correctly that, if we go down that road, there would only
> be a single exception (every failure will raise the same exception)?

No, not at all, but your exceptions would provide all the same mechanism to 
add valuable information up the stack. Have a look at the implementation of 
ContextException and ContextRuntimeException. It's quite hollow, the real 
code is in DefaultExceptionContext i.e. you could easily create also a 
IllegalArgumentContectException derived from IllegalArgumentException. And 
since the ExceptionContext is only an interface you might even replace ther 
DefaultExceptionContext with something like LOcalizedExceptionContext that 
has additional language support.

> If the aim is only for printing the whole context, it is indeed very
> flexible (adding a lot of info is easy). But if the caller wants to trap
> and act on a particular condition (a part of the context), isn't it more
> difficult than catching a specific exception?

As I said, keep the hierarchy, but you might be able to trim it down more 
easily, because you don't have to invent a new one simply because you want 
to provide an additional information.

> Examples are really needed to figure out the actual use-cases for CM and
> users of CM.


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

View raw message