commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: svn commit: r960602 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/analysis/interpolation/ main/java/org/apache/commons/math/exception/ main/java/org/apache/commons/math/util/ main/resources/META-INF/localization/ site/xdoc/ tes...
Date Mon, 05 Jul 2010 22:31:46 GMT
> > MATH-361
> > MATH-382
> In the future, please separate commits if possible for separate
> issues.  In this case, a bug was fixed and some exception
> refactoring was also introduced.  These should be separate commits

I know, and I do it whenever possible but I found out about the bug
(MATH-382) when I had already updated the file (MATH-361) and did not have
time to spend rolling back the changes for something that trivial.

> and changes.xml should be updated with entries for each.

There is already an entry about issue 361.
Do you really want that I duplicate that entry each time I work a little on
this issue?

> It would be great to discuss the exception refactoring some more.
> The commit below gives some concrete examples.  I would like to
> understand better why "NumberIsTooLargeException" and
> "NumberIsTooSmallException" are better abstractions than more
> domain-specific ones.

Of course we could have an exception package as big as the current list of

However, my opinion is that an exception is supposed to tell what went
wrong, not why. It simply cannot be a user's manual!

> Also, are we not losing information in stack
> traces when we do:
> >          if (x.length < 2) {
> > -            throw
> MathRuntimeException.createIllegalArgumentException(
> > -                  LocalizedFormats.WRONG_NUMBER_OF_POINTS, 2,
> x.length);
> > +            throw new NumberIsTooSmallException(x.length, 2, true);
> Perhaps another parameter identifying the quantity that is "too
> large" is needed?

The stack trace certainly will show where the bad thing happened.
Nothing important is lost: What went wrong is as clearly identified by
 "The argument must be >= 2"
as by saying
 "The number of points must be >= 2"
The problem is that the caller passed a wrong argument and this is a bug and
no amount of detailed message will be a substitute for reading the
documentation and source code and make the correct call.

Exceptions enhance the robustness of the library; they cannot premptively
prevent bad usage...

Best regards,

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

View raw message