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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
