Throw `InvalidFormatException` instead of `MismatchedInputException` for ACCEPT_FLOAT_AS_INT coercion failures

I 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.

[mjustin]

Here’s a simple test for the current behavior:

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.core.type.TypeReference;
import com.fasterxml.jackson.databind.DeserializationFeature;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.exc.MismatchedInputException;
import org.junit.jupiter.api.Test;

import java.math.BigInteger;
import java.util.List;
import java.util.Map;

import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.junit.jupiter.api.Assertions.assertTrue;

public class DisallowFloatAsIntTest {
    private ObjectMapper objectMapper = new ObjectMapper().disable(DeserializationFeature.ACCEPT_FLOAT_AS_INT);

    @Test
    public void exceptionIncludesProblematicValue() {
        testExceptionIncludesProblematicValue("5.5", Integer.class);
        testExceptionIncludesProblematicValue("5.0", Long.class);
        testExceptionIncludesProblematicValue("1234567890123456789.0", BigInteger.class);
        testExceptionIncludesProblematicValue("[4, 5.5, 6]", "5.5", new TypeReference<List<Integer>>() {});
        testExceptionIncludesProblematicValue("{\"key1\": 4, \"key2\": 5.5}", "5.5", new TypeReference<Map<String, Integer>>() {});
    }

    private void testExceptionIncludesProblematicValue(String value, Class<?> valueType) {
        JsonProcessingException e = assertThrows(MismatchedInputException.class,
                () -> objectMapper.readValue(value, valueType));
        assertTrue(e.getMessage().contains("('" + value + "')"));
    }

    private void testExceptionIncludesProblematicValue(String content, String value, TypeReference<?> valueType) {
        JsonProcessingException e = assertThrows(MismatchedInputException.class,
                () -> objectMapper.readValue(content, valueType));
        assertTrue(e.getMessage().contains("('" + value + "')"));
    }
}

[Blacklands]

It seems the same is happening when using the FAIL_ON_NULL_CREATOR_PROPERTIES and FAIL_ON_MISSING_CREATOR_PROPERTIES features for deserialization. These also cause just a MismatchedInputException 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!).