On Wed, Feb 2, 2011 at 4:23 AM, Luc Maisonobe <luc.maison...@free.fr> wrote: > Le 02/02/2011 05:54, Phil Steitz a écrit : >> 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 (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 ? >>> >> 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: >> http://s.apache.org/NNd >> It could be, though, that the embedded machinery might be useful and >> allowing users to add data to exception messages is a powerful feature. > > It seems the thread asking for help on the exception API design is going > to be fruitful, and it starts well with interesting ideas. I guess some > of these ideas will change again our view and we will converge > (hopefully not throwing an exception ourselves ...) to a stable design > for 3.0. It seems to me that the switch to unchecked exceptions is > supported by almost all participants to this thread, so this part is > probably already stabilized. > > I doubt we can do anything about it for 2.2 and waiting first for the > rest of the discussion to stabilize (no hierarchy/small hierarchy/large > hierarchy, specific getters/general context map ...) would push 2.2 too far. > > I would like to freeze 2.2 as it is now in the repository and get it out. > > What do you think ? >
+1 for getting the release out. Given that we are not sure how things are going to end up in 3.0, we should remove the deprecations. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org