Impossible to deserialize custom `Throwable` sub-classes that do not have single-String constructors

[Pass-Kal]

Search before asking

• I searched in the issues and found nothing similar.

Describe the bug

An UnrecognizedPropertyException is thrown on fields "message" and/or "suppressed" while deserializing a custom exception.
(since correction #3497)

Workaround : adding ".configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false)" (but with operationnal impact)

Version Information

2.14+

Reproduction

public class CustomException extends Exception{
public CustomException (){
super();
}
}

String json = JsonMapper.builder().build().writeValueAsString(new CustomException());
JsonMapper.builder().build().readValue(json, CustomException.class);

==> UnrecognizedPropertyException

Expected behavior

Deserialization is possible without disabling FAIL_ON_UNKNOWN_PROPERTIES

Additional context

Since f27df63
with the removal of "builder.addIgnorable("localizedMessage");" and "builder.addIgnorable("suppressed");" In class [BeanDeserializerFactory.java] (line 452 and line 454)

[JooHyukKim]

It seems what the commit f27df63 tried to solve in #3497 did not intend change of behavior decribed here.

Though it needs review by @cowtowncoder, #4072 might solve the problem.

[Pass-Kal]

Thanks for this fix.

I think it was not the intention but the removed lines have seemed unnecessary as it would have to be assumed by the ThrowableDeserializer.

For some reasons, I have the same problem on some other custom exceptions with the property "suppressed" (the getter is "getSuppressed" but the fied is "suppressedExceptions" and it was also ignored by the removed code in f27df63)

[JooHyukKim]

Thanks for this fix.

Np! Also, I only made a "possible" fix :)) I still probably need more time to figure out Jackson's behavior on Throwable's or its sub-classes.

For some reasons, I have the same problem on some other custom exceptions with the property "suppressed" (the getter is "getSuppressed" but the fied is "suppressedExceptions" and it was also ignored by the removed code in f27df63)

@Pass-Kal Could you also share the example case here? What is also possible is that #4072 will either

• fix a problem (possible regression)
• or revert back some other intended behavioral change made by f27df63

[cowtowncoder]

I merged #4072, which should handle message case.