On 2 February 2011 06:04, Phil Steitz <phil.ste...@gmail.com> 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 to. 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. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
