Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

encoding/json, encoding/xml: option to treat unknown fields as an error #6901

Closed
lukescott opened this issue Dec 6, 2013 · 10 comments

Comments

Projects
None yet
7 participants
@lukescott
Copy link

commented Dec 6, 2013

Currently unknown fields are silently ignored when decoding into a struct. I would like
to have an option to treat unknown fields as an error.

This would be extremely helpful for a REST API to help third-party developers identify
typos. In this particular case I don't need an "inline" tag as I don't need to
do anything with the extraneous fields. I just need to tell the recipient that they
included something the server doesn't understand.
@rsc

This comment has been minimized.

Copy link
Contributor

commented Mar 3, 2014

Comment 1:

Labels changed: added release-none.

Status changed to Accepted.

@gopherbot

This comment has been minimized.

Copy link

commented Jul 22, 2014

Comment 2 by Kyle.A.Wolfe:

I would also like to see this, as well as a path to the field(s) that were not
unmarshalled Something like this maybe?
type UnmarshalResult struct {
    Path          string //"foo>bar"
    Unmarshalled  bool
}
func xml.UnmashalWithResult(xmlBytes []byte, v interface{}) []*UnmarshalResult
Adding this method rather than modifying the existing Unmarshal method should keep
backwards compatibility as well as provide us with this most useful feature
@gopherbot

This comment has been minimized.

Copy link

commented Jul 22, 2014

Comment 3 by Kyle.A.Wolfe:

Additionally, using `xml:ALL` option is not viable for large and living xml documents.
Placing a catchall on the root of the element will only work if the entire child element
was missed: See foo>c>c2 not showing up as a missed field:
http://play.golang.org/p/g3KPa3g4Dm
@gopherbot

This comment has been minimized.

Copy link

commented Jul 26, 2014

Comment 4 by Kyle.A.Wolfe:

I created a fork and added this functionality (not fully tested)
@gopherbot

This comment has been minimized.

Copy link

commented Jul 26, 2014

Comment 5 by Kyle.A.Wolfe:

I have forked this package and added this functionality while keep backwards
compatibility (not fully tested) https://github.com/KyleWolfe/xmlkeys
@griesemer

This comment has been minimized.

Copy link
Contributor

commented Oct 1, 2014

Comment 6:

Labels changed: added repo-main.

@adg

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2015

One way to do this would be to add a Strict method to the Encoder and Decoder types. While we're at it we could also make indentation on Encoder possible with an Indent method.

@h4ck3rm1k3

This comment has been minimized.

Copy link

commented Mar 12, 2015

I have a simple patch for this for json #10134

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

@cespare

This comment has been minimized.

Copy link
Contributor

commented Apr 16, 2016

We should do this. Today, I'm aware of two workarounds:

  • Separately unmarshal the object into a map in order to obtain and inspect the key set.
  • Use pointers for all field values. For example, the github.com/google/go-github API wrapper uses pointer fields as a rule for this reason. (But even then, you can't distinguish between "k":null and a missing key.)

Besides some way to change the decoder "mode" (as @adg suggested), here's another way it could work: add a ,required struct field tag which causes Unmarshal to give an error if no key matches that field.

@adg

This comment has been minimized.

Copy link
Contributor

commented Jul 28, 2016

Closing this in favor of #15314, which is identical and more active.

@adg adg closed this Jul 28, 2016

@golang golang locked and limited conversation to collaborators Jul 28, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.