> > +1 - here is an idea that can likely be improved: > > IllegalArgumentException - thrown when the activated method itself > can ascertain that preconditions specified in the API expressed at > the level of the activated method have been violated. In the vast > majority of cases where [math] throws IllegalArgumentException, it > is the result of argument checking of actual parameters immediately > passed to a method. > > FunctionEvaluationException - may be advertised by a method that may > encounter errors evaluating a function. This *should* be thrown > only in circumstances where at the level of the activated function > IllegalArgumentException is not appropriate and it *should* indicate > that while formal preconditions of the method have not been > violated, an irrecoverable error has occurred evaluating a function > at some (usually lower) level of the call stack. Convergence > failures, runtime exceptions (even IllegalArgumentExceptions) in > user code or lower level methods can cause (and should be wrapped > in) FunctionEvaluationExceptions.
Added in revision 1032424. > >You could write a document that would explain how good it would be if all > >programs were using the same exceptions. But I must point out that CM isn't > >a good example, with its policy of no dependencies. Why would anyone depend > >on CM just for the sake of using CM exceptions? > > I think you are missing the point here - our APIs can encourage > consistent use of exceptions by user code that uses and/or > integrates with [math]. > > These are the kinds of things we need to talk about in refactoring > exceptions. Our API - including all advertised exceptions - needs > to help users understand what we - and they - are doing, not just > minimize the amount of code they need to write or simplify our lives > as maintainers. This is especially true of the more complex > algorithms and frameworks where user code plugs into [math]. We're probably not talking about the same things. And you are missing my points as much as I've missed yours. CM is a Java library that has many advantages, but before trying to give lessons to other programmers on "what they are doing", we should concentrate on internal improvements. The handling of exceptions is something that cannot come as an after-thought. I think that exceptions should primarily be useful *inside* the code base in which they are defined (even more so with checked ones) and not pre-suppose they will be handled in larger scopes. Here is a quote from Bruce Eckel at http://www.mindview.net/Etc/Discussions/CheckedExceptions: --- [...] it does agree that checked exceptions seem to be helpful for small projects, which is generally the space where we argue the point. However, when projects get large (actually, I've noticed it when they are anything except small), checked exceptions get ungainly and seem to cause problems. I would therefore suggest that the reason checked exceptions seem so compellingly "right" at first is that they have been presented and argued in the realm of small examples. --- Finally, I indeed share the opinion that clean, lean, and consistent code makes it more maintainable (and hence simplify the maintainer's lives). Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
