commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [all][math] Help wanted with exceptions API design
Date Wed, 02 Feb 2011 10:54:16 GMT
On Tue, Feb 01, 2011 at 10:40:47PM -0800, Stephen Williams wrote:
> On 2/1/11 10:04 PM, Phil Steitz wrote:
> >...
> >Agreed.  This is why we had a very flat hierarchy through version
> >2.0 of [math].  Where we are having trouble gaining consensus is how
> >to represent specializing context information in our exceptions and
> >what abstractions to use to represent the shallow hierarchy that we
> >aim to build.  For example, in 2.0, we have a ConvergenceException,
> >representing the commonly occurring scenario of type b) above where
> >an iterative algorithm has failed to converge.  This exception is
> >often caught and wrapped or recovered from internally in [math].  It
> >has a subclass, MaxEvaluationsExceededException to represent the
> >common convergence failure suggested by its name.  I personally
> >think we should keep this exception in 3.0.  Gilles thinks that we
> >should replace it by more granular exceptions like
> >"MaxCountExceeded" or "NotFiniteNumberException" (another reason
> >that a sequence can fail to converge) that have nothing to do with
> >convergence.  We are similarly at odds regarding
> >"FunctionEvaluationException" a top-level exception indicating that
> >an error has occurred evaluating a function.
> 
> One pattern that can make a lot of sense is to nest exceptions.  Or,
> as I've seen in C++, to put errors in a queue to generalize and
> extend the errno concept.  The idea is that sometimes you want to
> know what an exception meant at each level of the code or at each
> conceptual level.  So you could 'throw new FailedToConverge(new
> MaxCountExceeded)' and have a standard way to follow the path like:
> ex.why().  This should result in a lot less exceptions that provide
> more expressiveness, plus it takes less code to do simple handling
> of failures: catching a single FailedToConverge for many possible
> causes for instance.

Indeed. And we are actually using this pattern already.

Best,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message