Hi. > [...] > > Trap for retry errors should be rare if present at all. I would much > > prefer to see a proper result object which everyone is forced to check > > to describe the success or failure of something that might be retried. > "Retry" is not in general meaningful for our stuff, though in a > small number of cases, "try a different algorithm" or "try a > different starting point" , "adjust parameters and retry" or > "return a special value" (all of which [math] code does internally > at different places) can be reasonable.
Even in those cases, this is not what is meant by "fail and retry" because the error is not caught and acted on within CM (no automation). Valid cases for a retry policy (supported by checked exception) is provided in J. Bloch's book (lots of advertisements, but I have no shares ;-) > 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] > > Of course, we have no way of distinguishing b) and c) and a fair > amount of our JIRA work really comes down to viewing b) problems as > c) problems (increasing the effective domains of our implementations). > > In general though, the main advice is to keep it simple. People rarely > > use exception hierarchies. Mostly they want the message to be readable > > to diagnose the problem in a stack trace. > 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. This is not an accurate representation of my position. If you reread some posts, you'll see that I have agreed that the combination of both (i.e. "ConvergenceException" wrapping the lower-level one) is the best representation of the actual problem as CM sees it. > We are similarly at odds regarding > "FunctionEvaluationException" a top-level exception indicating that > an error has occurred evaluating a function. We are at odds here because the issue is different: CM never "sees" the exception (i.e. it doesn't represent an abstraction which CM would want to act on; also, CM doesn't catch it because it cannot handle it). So, my position is to not "pollute" the CM library with a class that we have no use for. Continuing from a comment about API boundaries in my previous post, the "FunctionEvaluationException" abstraction belongs to the other side of the API boundary. > > [...] Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
