> > 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
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.
Exceptions enhance the robustness of the library; they cannot premptively
prevent bad usage...
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
