> > [...] > > > > Has anyone of you considered the usage of an exception context? We > > introduce > > this with lang3 (http://commons.apache.org/lang/api-3.0- > > 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)? 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? Examples are really needed to figure out the actual use-cases for CM and users of CM. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
