RFR: 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
Fabian Meumertzheim
github.com+4312191+fmeum at openjdk.java.net
Wed Apr 21 16:54:30 UTC 2021
On Wed, 21 Apr 2021 16:27:14 GMT, Joe Darcy <joe.darcy at oracle.com> wrote:
> Just was we don't think it is helpful to put an explicit
>
> @throws NullPointerException if a argument is null
>
> on every method that throws a NPE for a null argument, I don't think it
> is helpful or necessary to explicitly note in every BigDecimal method
> with rounding that it could throw ArithmeticException. The general
> class-level statement
>
> ?* <p>As a 32-bit integer, the set of values for the scale is large,
> ?* but bounded. If the scale of a result would exceed the range of a
> ?* 32-bit integer, either by overflow or underflow, the operation may
> ?* throw an {@code ArithmeticException}.
>
> in meant to capture the needed information.
>
> -Joe
I do agree with this in general, but I think that the situation at hand is a bit different from your example for two reasons:
* The `BigDecimal` class already contains many explicit `@throws` annotations for `RuntimeException`s. The absence of such an annotation from a particular method would thus naturally be interpreted as saying that the method does not throw.
* For someone not intimately familiar with the internal representation of `BigDecimal`s, it is probably quite unexpected that a function called `stripTrailingZeros` would perform rounding and thus be liable to scale overflows. (This is what happened to the maintainers of jackson-core, where this lead to an unexpected RuntimeException that was only discovered via fuzzing. They simply took this function to perform some kind of "harmless" canonicalization.)
That is why I do see value in adding these annotations in this particular case.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3189
More information about the core-libs-dev
mailing list