Throw `InvalidFormatException` instead of `MismatchedInputException` for ACCEPT_FLOAT_AS_INT coercion failures
See original GitHub issueI noticed that when ACCEPT_FLOAT_AS_INT
is disabled, the application throws MismatchedInputException
. It seems InvalidFormatException
would be a good fit here, with the benefit of programmatically exposing the value that failed conversion.
I noticed this since I’ve added some custom handling in my application for InvalidFormatException
/MismatchedInputException
to provide terser/more user-appropriate errors. Since this scenario throws MismatchedInputException
, I cannot programmatically retrieve the JSON value that failed to serialize. If it did implement InvalidFormatException
, I could use InvalidFormatException.getValue()
to get the value.
Note: This same reasoning applies to other similar features, such as ALLOW_COERCION_OF_SCALARS
& FAIL_ON_NULL_FOR_PRIMITIVES
.
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (4 by maintainers)
Here’s a simple test for the current behavior:
It seems the same is happening when using the
FAIL_ON_NULL_CREATOR_PROPERTIES
andFAIL_ON_MISSING_CREATOR_PROPERTIES
features for deserialization. These also cause just aMismatchedInputException
to be thrown. The information (the name and index of the attribute that was null/missing) is in the exception message, so it should be possible to throw a more specific exception that also contains these as fields, right?For now, I suppose I will have to parse the exception message to obtain this information (which is very hacky and prone to break, I know!).