On Mon, 9 Jun 2025 22:08:08 GMT, Naoto Sato <na...@openjdk.org> wrote:
>> Sorry, I'm not seeing where the original could throw ParseException. > > Sorry if I was unclear. I mean the `parse()` in the NumberFormat do not throw > NumberFormatException/ArithmeticException, but ParseException, so if this > piece of code need to throw something, it should be `ParseException` The `parse()` methods where this code gets used in `DecimalFormat` don't throw `ParseException`. The current calls to `getLong` always are guarded with a call to `fitsIntoLong`, which should avoid any exceptions actually being thrown here. So there is no parse failure as such - instead it tries to parse it as a `double` or a `BigDecimal`. If getLong were to be called without the guard, the exception would have come from `Long.parseLong`, which throws a `NumberFormatException`. I've added a commit to follow @liach's suggestion to at least rethrow the ArithmeticException so as to not introduce new exceptions into the mix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136611661
