commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Williams <...@lig.net>
Subject Re: [all][math] Help wanted with exceptions API design
Date Wed, 02 Feb 2011 06:40:47 GMT
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.

The two choices for composition exceptions like this are A) nesting or B) a stack or queue.
 They both have good points.

> ...
> Phil
sdw


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


Mime
View raw message