Hi. > My new approach to coding. Say what you see. Expressed with other words, but that's indeed what I'm suggesting for CM.
> 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 Although, as previously stated, because of requirement constraints, it cannot be as terse. > > 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. Not necessarily, beacuse CM is a relatively "flat" library: lots of algorithms but no deep-nesting of function calls. > Personally, I don't believe you need everything available, and I > struggle to think of other projects where it is. In CM, this is just one of the requirements: Not losing any information. > 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. Again, it is not CM that should decide whether the caller wants to act differently on different exceptions. Also, IIUC "say what you see", than if you see "A", you say "A", not "a superclass of A". > > 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. I totally agree that there should be a limit on the number of such features but drawing the line is difficult because the developers have varying views on what is important :-). Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
