> -----Original Message-----
> From: Luc Maisonobe [mailto:luc.maison...@free.fr]
> Sent: Tuesday, February 01, 2011 14:07
> To: Commons Developers List
> Subject: Re: [all][math] Help wanted with exceptions API design
>
> 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 ?
It /does/ look interesting for sure.
Gary
>
> Luc
>
> >
> > try {
> > geneticAlg.evolve(pop, cond)
> > } catch (MathException ex) {
> > ex.addValue("Initial Population Size", pop.getPopulationSize());
> > throw ex;
> > }
> >
> > Additionally this approach tends to shorten the prosa, because the
> algorithm
> > might throw:
> >
> > if (population.getPopulationSize() == 0) {
> > MathException ex = new MathException("Population died");
> > ex.addValue("Iterations", getGenerationsEvolved());
> > throw ex;
> > }
> >
> > instead of:
> >
> > if (population.getPopulationSize() == 0) {
> > throw new MathException("Population died after " +
> getGenerationsEvolved()
> > + " generations, starting with " + initialSizeKeptSomewhere + "
> > chromosomes");
> > }
> >
> > Even if you keep i18n, it is easier to translate the short messages and
> the
> > param keys instead of the full text ;-)
> >
> > ... 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.
> >
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
