When JsonDeserializer.deserialize throws an exception, wrap it and include the path of the JsonElement to make troubleshooting easier.
Risks of this approach:
Troubleshooting might still be difficult / confusing because it is not obvious that the path reported by the wrapped exception is relative
User code might expect the exception to be propagated without any wrapping
If users use a lot JsonDeserializers and a deeply nested one throws an exception, it would create a large exception chain, which is difficult to read and could be a performance issue
:warning: So I am not completely sure if this is worth it. Feel free to reject this pull request (or suggest another solution).
Checklist
[x] New code follows the Google Java Style Guide\
This is automatically checked by mvn verify, but can also be checked on its own using mvn spotless:check.\
Style violations can be fixed using mvn spotless:apply; this can be done in a separate commit to verify that it did not cause undesired changes.
[ ] If necessary, new public API validates arguments, for example rejects null
[ ] New public API has Javadoc
[ ] Javadoc uses @since $next-version$
($next-version$ is a special placeholder which is automatically replaced during release)
[x] If necessary, new unit tests have been added
[x] Assertions in unit tests use Truth, see existing tests
[x] No JUnit 3 features are used (such as extending class TestCase)
[x] If this pull request fixes a bug, a new test was added for a situation which failed previously and is now fixed
[x] mvn clean verify javadoc:jar passes without errors
Purpose
Resolves #1135
Description
When
JsonDeserializer.deserializethrows an exception, wrap it and include the path of theJsonElementto make troubleshooting easier.Risks of this approach:
JsonDeserializers and a deeply nested one throws an exception, it would create a large exception chain, which is difficult to read and could be a performance issue:warning: So I am not completely sure if this is worth it. Feel free to reject this pull request (or suggest another solution).
Checklist
mvn verify, but can also be checked on its own usingmvn spotless:check.\ Style violations can be fixed usingmvn spotless:apply; this can be done in a separate commit to verify that it did not cause undesired changes.null@since $next-version$(
$next-version$is a special placeholder which is automatically replaced during release)TestCase)mvn clean verify javadoc:jarpasses without errors