Honor @JsonView in ThrowableDeserializer.deserializeFromObject()

[aysha-afrah26]

BeanDeserializer and its array and builder variants skip properties that fall outside the active @JSONVIEW, but ThrowableDeserializer overrides deserializeFromObject on its own to handle the special message and cause construction, and that override never looked at the view. It only bites exceptions that reach this loop rather than the property-based-creator path: a Throwable with a default constructor and no @JsonCreator, where the remaining fields are plain setters. Under a restricted view those fields are still read straight from input, so a property that belongs only to another view (say an internal-only field on a custom exception) gets populated by a caller reading under a narrower view. I noticed it while checking which deserializers consult _needViewProcesing and this was the only property loop that did not. The fix reads the active view once and skips any property not visible in it before the value is set or deferred, matching what deserializeWithView already does, including the FAIL_ON_UNEXPECTED_VIEW_PROPERTIES behavior. I kept the change inside deserializeFromObject so the creator and any-setter paths are untouched.

[github-actions]

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	81.42%	📉 -0.010%
Branches	74.76%	📈 +0.000%

Coverage data generated from JaCoCo test results

[github-actions]

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	81.42%	📉 -0.020%
Branches	74.76%	📉 -0.010%

Coverage data generated from JaCoCo test results

[github-actions]

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	81.43%	📉 -0.010%
Branches	74.77%	📈 +0.010%

Coverage data generated from JaCoCo test results

[cowtowncoder]

This may be problematic for common use cases due to 3.x enabling of MapperFeature.DEFAULT_VIEW_INCLUSION by default -- we do NOT want to start dropping standard properties like cause or localizedMessage just because they have no @JsonView associated. So basically Throwables are not regular POJOs; only sub-type properties should follow view-limitations.

EDIT: apparently only problematic with stackTrace

[gitar-bot]

💡 Edge Case: Standard-prop exemption bypassed by property naming strategy

_isStandardThrowableProperty matches property names with a case-sensitive switch on the literal Throwable names (cause, stackTrace, etc.). Under a PropertyNamingStrategy that renames properties (e.g. upper-camel), prop.getName() no longer equals these literals, so the standard property is not exempted and would again be filtered out under a restricted view. This is consistent with the pre-existing naming-strategy limitation noted at the message handling (databind#3497), so it is a minor gap rather than a regression; if broader coverage is desired, compare against the mangled names as done elsewhere.

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

Code Review 👍 Approved with suggestions 0 resolved / 1 findings

Fixes @JsonView bypass in ThrowableDeserializer.deserializeFromObject() by checking the active view before populating properties, matching the behavior of BeanDeserializer. Consider that _isStandardThrowableProperty uses case-sensitive literal matching and may not recognize properties renamed by a PropertyNamingStrategy, causing standard properties to be filtered under a restricted view—a minor gap consistent with existing naming-strategy limitations noted in databind#3497.

💡 Edge Case: Standard-prop exemption bypassed by property naming strategy

📄 src/main/java/tools/jackson/databind/deser/jdk/ThrowableDeserializer.java:329-339 📄 src/main/java/tools/jackson/databind/deser/jdk/ThrowableDeserializer.java:135-136

_isStandardThrowableProperty matches property names with a case-sensitive switch on the literal Throwable names (cause, stackTrace, etc.). Under a PropertyNamingStrategy that renames properties (e.g. upper-camel), prop.getName() no longer equals these literals, so the standard property is not exempted and would again be filtered out under a restricted view. This is consistent with the pre-existing naming-strategy limitation noted at the message handling (databind#3497), so it is a minor gap rather than a regression; if broader coverage is desired, compare against the mangled names as done elsewhere.

🤖 Prompt for agents

Code Review: Fixes `@JsonView` bypass in `ThrowableDeserializer.deserializeFromObject()` by checking the active view before populating properties, matching the behavior of `BeanDeserializer`. Consider that `_isStandardThrowableProperty` uses case-sensitive literal matching and may not recognize properties renamed by a `PropertyNamingStrategy`, causing standard properties to be filtered under a restricted view—a minor gap consistent with existing naming-strategy limitations noted in databind#3497.

1. 💡 Edge Case: Standard-prop exemption bypassed by property naming strategy
   Files: src/main/java/tools/jackson/databind/deser/jdk/ThrowableDeserializer.java:329-339, src/main/java/tools/jackson/databind/deser/jdk/ThrowableDeserializer.java:135-136

   `_isStandardThrowableProperty` matches property names with a case-sensitive `switch` on the literal Throwable names (`cause`, `stackTrace`, etc.). Under a `PropertyNamingStrategy` that renames properties (e.g. upper-camel), `prop.getName()` no longer equals these literals, so the standard property is not exempted and would again be filtered out under a restricted view. This is consistent with the pre-existing naming-strategy limitation noted at the `message` handling (databind#3497), so it is a minor gap rather than a regression; if broader coverage is desired, compare against the mangled names as done elsewhere.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source}

[cowtowncoder]

Changed to include "standard" properties regardless.

[github-actions]

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	81.44%	📈 +0.000%
Branches	74.76%	📈 +0.000%

Coverage data generated from JaCoCo test results