encoding/json: Unmarshal not reporting on skipped fields

[h4ck3rm1k3]

When un-marshalling the json decoder will skip fields if it does not match the name.
This can be problematic if you have a typo or have a new field in the json. Would like some feedback from the decode modules when this happens.

Originally described in #10134

See also on stack overflow
http://stackoverflow.com/questions/20509444/go-json-unmarshal-not-picking-up-a-single-attribute-value
http://stackoverflow.com/questions/20943963/json-unmarshal-doesnt-seem-to-pay-attention-to-struct-tags

Proposed solution is to add this line to report unmatched fields
d.saveError(fmt.Errorf("json: unmatched field %s for %v", key, v.Type()))
h4ck3rm1k3/google-go@3befeea#diff-4299c3082a8bb7e546723132c992fa4cR586

[adg]

It's a feature of encoding/json that you can drop fields you're not
interested in, and that you can have more fields in the destination struct
than are in the source JSON object. Reporting unmatched fields as an error
breaks that feature, and it also breaks backward-compatibility (See
https://golang.org/doc/go1compat).

I could imagine writing a little tool to take some source JSON and a
destination struct (and vice versa) and check that they fit together, but
the mismatch certainly should not be an error condition for the package.

On 12 March 2015 at 12:42, James Michael DuPont [email protected]
wrote:

When un-marshalling the json decoder will skip fields if it does not match
the name.
This can be problematic if you have a typo or have a new field in the
json. Would like some feedback from the decode modules when this happens.

Originally described in #10134 #10134

See also on stack overflow

http://stackoverflow.com/questions/20509444/go-json-unmarshal-not-picking-up-a-single-attribute-value

http://stackoverflow.com/questions/20943963/json-unmarshal-doesnt-seem-to-pay-attention-to-struct-tags

Proposed solution is to add this line to report unmatched fields
d.saveError(fmt.Errorf("json: unmatched field %s for %v", key, v.Type()))
h4ck3rm1k3/google-go@3befeea#diff-4299c3082a8bb7e546723132c992fa4cR586
h4ck3rm1k3/google-go@3befeea#diff-4299c3082a8bb7e546723132c992fa4cR586

—
Reply to this email directly or view it on GitHub
#10140.

[h4ck3rm1k3]

It would be great to have an optional warning if possible, or some callback routine that could be installed. I found this patch greatly useful in developing. Otherwise I ended up re-implementing the decoding routine to find the problem.

[adg]

There's nothing wrong with copying and pasting code. The hypothetical tool
could include the modified json package.

On 12 March 2015 at 12:54, James Michael DuPont [email protected]
wrote:

It would be great to have an optional warning if possible, or some
callback routine that could be installed. I found this patch greatly useful
in developing. Otherwise I ended up re-implementing the decoding routine to
find the problem.

—
Reply to this email directly or view it on GitHub
#10140 (comment).

[h4ck3rm1k3]

I found it quite difficult to copy and paste the code because I had to copy the entire module because of undercased private functions that I could not call. Would need to make them public. In any case this would be a simple feature to add and would not break any compatibility to have an optional warning or strict mode.

[cespare]

I agree that this would be a useful option.

This issue has been brought up before and is already tracked by #6901.

[adg]

Closed as a dupe

[adg]

@h4ck3rm1k3 I meant literally copy the encoding/json directory somewhere else.

[h4ck3rm1k3]

yes that is what I had to do. My patch was based on that effort. @adg . thanks for the feedback