-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MapDeserializer
forcing JsonMappingException
wrapping even if WRAP_EXCEPTIONS set to false
#3068
Comments
It does sound like a flaw: I wish I could give a definitive statement but I think that a reproduction would help answer this question. The main caveat is that only Assuming this is a flaw to fix, I'd have to figure out if it is small enough change it could go in 2.12.2 or 2.13.0. |
I have tried to create a toy example which hits WrapsAndThrows in ContainerDeserializerBase. |
MapDeserializer
forcing JsonMappingException
wrapping even if WRAP_EXCEPTIONS set to false
Was straight-forward to fix and I think likelihood of regression is low (affects regular Map and EnumMap deserializers), so including it in 2.12 branch for upcoming 2.12.2 patch. |
Thanks tested against the snapshot 2.12.3-SNAPSHOT and it fixed the real scenario |
@perkss great, that you for verifying it. Hoping to release 2.12.2 quite soon now, within a week. |
Describe the bug
I am upgrading a project from 1.9.13 to 2.12.1. The WRAP_EXCEPTION feature was added in since that as we have a custom exception now being wrapped.
The project adds a Deserializer and overrides deserialize where it throws a custom exception. We do not want this exception to be wrapped but it now gets wrapped as a JsonMappingException. Even setting WRAP_EXCEPTION to false it still wraps the exception.
The code calls wrapAndThrow and then wraps the exception ContainerDeserializerBase.
Then when handled as its already been wrapped by a
JsonMappingException
it is a instance ofIOException
so it will not unwrap the exception in the code BeanDeserializerBase.Should we be able to get the underlying exception here or is this by design to force this wrapping?
Version information
2.12.1
To Reproduce
Expected behavior
<jacksonissue.CustomException> but was: <com.fasterxml.jackson.databind.JsonMappingException>
Additional context
This is due to trying to upgrade Apache Samza from a very old Jackson version where they throw an exception like the case above referenced here
The text was updated successfully, but these errors were encountered: