commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject RE: [all][math] Help wanted with exceptions API design
Date Tue, 01 Feb 2011 19:11:46 GMT
> -----Original Message-----
> From: Luc Maisonobe [mailto:Luc.Maisonobe@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org

Mime
View raw message