commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [Math] FunctionEvaluationException in UnivariateRealFunction
Date Mon, 08 Nov 2010 00:50:58 GMT
> +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
[...] 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).


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

View raw message