commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
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 Tue, 06 Jul 2010 07:41:32 GMT
Le 06/07/2010 02:55, Phil Steitz a écrit :
> Gilles Sadowski wrote:
>>>> 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.
> As I said, please separate commits in the future.  It is not that
> difficult to svn revert and manage source so your local mods for
> different issues can be separated.  Commit logs and diffs get
> attached to issues and it makes it easier to tell what has happened
> if we separate commits for different issues.
>>> 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?
> What I tend to do is create an entry in changes.xml for an issue in
> progress and update it to reflect the changes associated with the
> issue.  We use changes.xml as the source for the release notes, so
> it should include references to all new classes, refactoring or
> other significant changes to to the code.
>>> 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
>> enums:
>>   NumberOfFooIsTooSmallException
>>   NumberOfBarIsTooSmallException
>>   etc.
>> 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
>> saying
>>  "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.
> Sorry, but I disagree here.  There is definitely loss of information
> in the stack trace. I would prefer to retain the detailed error

I also disagree with Gilles, but not the same reason. Some people will
not have access to the stack trace. It is even more important for
unchecked exception since they may not be intercepted by high level
applications. All they will get is a terse message print on a log file
or a popup window before the application stops.

Users are not here to debug the code for developers.

Also the Apache license allows people to reuse our code in proprietary
environment with closed source. For sure in this case, no stack trace
will be available.


> message that tells what quantity was "too small."  And I do not
> really see the value in the "NumberTooSmallException" altogether,
> frankly.  By substituting an exception that does not identify what
> quantity was "too small" for an IllegalArgumeentException with a
> message giving the full context, what exactly have we achieved?
> Phil
>> Exceptions enhance the robustness of the library; they cannot premptively
>> prevent bad usage...
>> Best regards,
>> Gilles
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message