Support handlers for unknown properties, useful for error handling

[GoogleCodeExporter]

What steps will reproduce the problem?
1. create a JSON string containing extra attributes
2. invoke Gson.fromJson supplying a class with fewer elements
3. GSON successfully instantiates the class without protesting about the 
existence of extra attributes in the string.

What is the expected output? What do you see instead?
1. define class A containing two fields: name and surname
2. define class B containing only one field: name
3. transform an instance of class A to Json string and use the Json string 
to create an instance of class B.

GSON doesn't complain. Even if this is the intended behavior, shouldn't 
there be an option to enforce stricter parsing?

What version of the product are you using? On what operating system?
gson-1.4

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 22 Jan 2010 at 10:13

Attachments:

• Converter.java

[GoogleCodeExporter]

I think a reasonable fix for this would be to permit the user to register a 
handler to be notified whenever an unknown property is encountered. Perhaps 
this:
  interface UnknownFieldHandler {
    void handle(JsonObject object, String name, JsonElement value);
  }

Then we could build in a few implementations: one that ignores unknown fields, 
one that logs unknown fields, and one that throws on unknown fields. Users 
could configure their GSON to be as strict or forgiving as necessary.

Original comment by limpbizkit on 3 Nov 2010 at 4:53

• Changed title: Support handlers for unknown properties, useful for error handling
• Added labels: Type-Enhancement, Milestone-Release1.7
• Removed labels: Type-Defect

[GoogleCodeExporter]

Issue 262 has been merged into this issue.

Original comment by limpbizkit on 30 Dec 2011 at 6:38

[GoogleCodeExporter]

It is good to get object instance, but also is useful information about 
character position.

Original comment by [email protected] on 30 Dec 2011 at 7:33

[GoogleCodeExporter]

Original comment by limpbizkit on 12 Feb 2012 at 8:44

• Removed labels: Milestone-Release1.7

[GoogleCodeExporter]

Yuk

Original comment by [email protected] on 3 Dec 2012 at 6:18

[GoogleCodeExporter]

A handler might not be very Gsonic, but some way to let the Gson client know 
that extraneous metadata existed in the subject JSON would be useful.

Original comment by [email protected] on 7 Jan 2013 at 9:05

[GoogleCodeExporter]

we have been hacked and have not agreed to your terms

Original comment by [email protected] on 13 Jan 2013 at 2:17

[GoogleCodeExporter]

please help get these people out of our stuff. fbi has been notified and law 
enforcement report filed. sincerely,
                           the real timpyates

Original comment by [email protected] on 13 Jan 2013 at 2:19

[GoogleCodeExporter]

Original comment by limpbizkit on 4 Feb 2013 at 4:00

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Issue 495 has been merged into this issue.

Original comment by limpbizkit on 4 Feb 2013 at 4:01

[GoogleCodeExporter]

Any new about this enhancement ? or a workaround ?

Original comment by [email protected] on 11 Mar 2014 at 9:41

[mcerina]

I submitted pull request #660 for this

[avarabyeu]

Any updates on this issue? looking forward for the fix...

[pratapkishorevarma]

Is there a workaround for this issue which we can do until a fix is provided?

[ikus060]

I manage to workaround this issue using a class similar to the following:

public class ValidatorAdapterFactory implements TypeAdapterFactory {

    @Override
    public <T> TypeAdapter<T> create(Gson gson, TypeToken<T> type) {
        // If the type adapter is a reflective type adapter, we want to modify the implementation using reflection. The
        // trick is to replace the Map object used to lookup the property name. Instead of returning null if the
        // property is not found, we throw a Json exception to terminate the deserialization.
        TypeAdapter<T> delegate = gson.getDelegateAdapter(this, type);

        // Check if the type adapter is a reflective, cause this solution only work for reflection.
        if (delegate instanceof ReflectiveTypeAdapterFactory.Adapter) {

            try {
                // Get reference to the existing boundFields.
                Field f = delegate.getClass().getDeclaredField("boundFields");
                f.setAccessible(true);
                Map boundFields = (Map) f.get(delegate);

                // Then replace it with our implementation throwing exception if the value is null.
                boundFields = new LinkedHashMap(boundFields) {

                    @Override
                    public Object get(Object key) {

                        Object value = super.get(key);
                        if (value == null) {
                            throw new JsonParseException("invalid property name: " + key);
                        }
                        return value;

                    }

                };
                // Finally, push our custom map back using reflection.
                f.set(delegate, boundFields);

            } catch (Exception e) {
                // Should never happen if the implementation doesn't change.
                throw new IllegalStateException(e);
            }

        }
        return delegate;
    }

}

[Killdozer65]

Thanks @ikus060. I was able to adapt your approach so I can log error messages on unrecognized properties, rather than silently ignoring them as is done by default.

[ikus060]

The solution is a bit ugly, but it work...

[hardiksoni13]

Do we have this fix as part of the GSON library now ?

[adam42a]

Nice work-around but I will have to adapt it to be compatible with my IdExclusionStrategy that tells gson to ignore the id field. Gson now throws errors wherever it sees the id in JSON.

My intention is to ignore ids on serialization, and by design it would be compatible because the TypeAdaptor for this example is only implemented for gets / deserialization. However ExclusionStrategies are deserialization/serialization-agnostic - work on both.

EDIT: ok, I have adapted the work-around for us with ExclusionStrategies by building two Gson objects, one for serializing, one for deserializing.

[cynthux]

Any updates on this issue? It was bumped to "Critical" priority three years ago.

[JavierSegoviaCordoba]

Up

[norbdev]

Up

[ataraxus]

wow, this is astounding... definitely moving away from gson. why is this basic feature not present?

[rubearen]

I'm looking for an alternative to gson, this problem should have been fixed in the last 10 years

[evanbross]

Still not fixed????
This seems to be a pattern with google tools, develop something 80% to 90% and then walk away from it :(

[ghost]

up

[luca-colazzo]

Imagine not resolving a critial-labeled issue in 11 years

Original issue reported on code.google.com by [email protected] on 22 Jan 2010 at 10:13

• Added labels: Priority-Critical

Oh right...

[evanbross]

This is why I've been moving away from google libraries. They have a solid history of abandoning projects and ignoring issues with them.

…

On Sat, May 15, 2021 at 10:11 AM Luca ***@***.***> wrote: Imagine not resolving a critial-labeled issue in 11 years Original issue reported on code.google.com by ***@***.*** on 22 Jan 2010 at 10:13 - Added labels: *Priority-Critical* Oh right... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZTL5SKWU4YBZHFLESM2S3TNZ6HPANCNFSM4BI4KC7Q> .

[lilmayu]

This would be especially great if you are parsing a huge chunk of JSON and you are unsure if you have defined all fields.

[JavierPAYTEF]

I will check the adapter to see if I can make it work, really strange this has been around for so long

[rdhzl]

Is anyone else here leveraging @ikus060 's example and has upgraded to Gson 2.10. It seems that:

delegate.getClass().getDeclaredField("boundFields");

now throws a java.lang.NoSuchFieldException. Trying to understand if there's an alternative.

[eamonnmcmanus]

The boundFields field is now in the superclass of the class returned by delegate.getClass(). So the code should work with 2.10 if you change that line to

        Field f = delegate.getClass().getSuperclass().getDeclaredField("boundFields");

We had to fix a couple of occurrences of the same problem in Google's internal codebase. I changed the code to this slightly more robust version:

        Field f = findField(delegateAdapter.getClass(), "boundFields");
...
  private static Field findField(Class<?> startingClass, String fieldName)
      throws NoSuchFieldException {
    for (Class<?> c = startingClass; c != null; c = c.getSuperclass()) {
      try {
        return c.getDeclaredField(fieldName);
      } catch (NoSuchFieldException e) {
        // OK: continue with superclasses
      }
    }
    throw new NoSuchFieldException(fieldName + " starting from " + startingClass.getName());
  }

That should work with both pre- and post-2.10 versions.

Although Gson is in maintenance mode, this particular issue seems important enough that we should have some formal support for it instead of requiring people to use reflective hacks like this.

[rdhzl]

@eamonnmcmanus Thank you for your follow-up! I agree it would be preferable to not have to use reflection to get at these fields, and it would be great if there were a more formal mechanism.

[marinat]

up