commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [all][math] Help wanted with exceptions API design
Date Tue, 01 Feb 2011 19:06:36 GMT
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 ?

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