fix: AtomicIntegerArray null element produces misleading error - #3095
Jerryyy985 wants to merge 1 commit into
Conversation
`ATOMIC_INTEGER_ARRAY` reads elements via raw `in.nextInt()` and only catches `NumberFormatException`; a JSON null element escapes as `IllegalStateException` wrapped in a misleading adapter-not-null-safe JsonSyntaxException. Fix: mirror `atomicLongArrayAdapter` (google#3038) — factory-based adapter that reads elements through a Number TypeAdapter and throws a clean `JsonSyntaxException("null is not a valid AtomicIntegerArray element")` on null. Fixes google#3047
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
Thanks! Instead of delegating to the
The hint says though "a built-in adapter does not support JSON null values", so it might not be completely misleading. But any PR for improving the Troubleshooting Guide is welcome! My main concern here is if this change is really needed. #3038 was definitely an issue because it fixed a I suspect only few users actually deserialize
(Note that I am not a direct member of this project; this is my personal opinion on this.) |
| while (in.hasNext()) { | ||
| Number value = intAdapter.read(in); | ||
| if (value == null) { | ||
| throw new JsonSyntaxException("null is not a valid AtomicIntegerArray element"); |
There was a problem hiding this comment.
Would probably be good to include in.getPreviousPath() here in the exception messsage, see also #3096
Gson.fromJson is documented to throw JsonSyntaxException for malformed input, but four groups of built-in adapters let raw NumberFormatException, IllegalArgumentException or NullPointerException escape to the caller. Callers that guard with catch (JsonParseException) do not catch these. This is the same defect class already fixed for AtomicLongArray in google#3038 and currently open for AtomicIntegerArray in google#3047 / google#3095. In each case the neighbouring target type already behaves correctly. - BitSet with a malformed number - null elements in primitive arrays (int[], double[], char[], ...) - double/float with a malformed number - null elements in collections that reject them (TreeSet, ArrayDeque, PriorityQueue, EnumSet)
This branch has not been deployed
2 participants
Summary
ATOMIC_INTEGER_ARRAYreads elements via rawin.nextInt()and only catchesNumberFormatException; a JSON null element escapes asIllegalStateExceptionwrapped in a misleadingadapter-not-null-safeJsonSyntaxException (with a wrong troubleshooting hint).Fix
Mirror
atomicLongArrayAdapter(from #3038): factory-based adapter reading elements through a Number TypeAdapter, throwing a cleanJsonSyntaxException("null is not a valid AtomicIntegerArray element")on null. Registered symmetrically in GsonBuilder.Verified:
[1,null,3]now produces the same clean error as AtomicLongArray; normal/empty/top-level-null paths unaffected.Fixes #3047