commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [all][math] Help wanted with exceptions API design
Date Wed, 02 Feb 2011 09:06:37 GMT
On 2 February 2011 06:04, Phil Steitz <> wrote:
> What we report back to the application using [math] is that one of
> the following kinds of bad things has happened
> a) they have violated preconditions - they get
> MathIllegalArgumentException (same semantics as anywhere else)
> b) they have not violated preconditions, but a numerical problem has
> occurred (while not violating stated preconditions, their problem is
> not in the effective domain of the algorithm they asked [math] to
> execute)
> c) they have hit a bug in [math]

My new approach to coding. Say what you see.

a) is IllegalArgEx (JDK) or a subclass.
b) is CalculationException or a subclass if there is truly valuable info to add
c) some other random RuntimeException

> 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.

If you are determined to have every single piece of information
extractable, the you'll need the detailed deep exception hierarchy.

Personally, I don't believe you need everything available, and I
struggle to think of other projects where it is.

If you insist on having everything available, then a map of data in a
shallow hierarchy of exceptions (probably only CalcEx->ConvergeEx, and
no more) is definitely preferable.

Essentially, I think the criteria is that you need different
exceptions if it is reasonable to perform different actions. I
personally doubt that a user wants to take a different action on
MaxEvaluationsExceededException, MaxCountExceeded or
NotFiniteNumberException. As was suggested, they are events to react

Finally, remember to design for the 80-99% use case, not the 100% one.
ie. just because you can imagine someone somewhere possibly wanting to
do something is no reason whatsoever to do it. You need to be
convinced that the majority might need it.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message