encoding/json: include field name in unmarshal error messages

[gopherbot]

by hitesh.jasani:

Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. Run http://play.golang.org/p/6UeIwpPMGU
2.
3.

What is the expected output?

An error message indicating which field caused the unmarshaller to choke.  Something
like "json: cannot unmarshal number into Go value of type string for key/name
'Zip'"

What do you see instead?

"json: cannot unmarshal number into Go value of type string"

Which compiler are you using (5g, 6g, 8g, gccgo)?

default compiler

Which operating system are you using?

OS X 10.9 (13A603)

Which version are you using?  (run 'go version')

go version go1.2rc3 darwin/amd64

Please provide any additional information below.

In the example I provided, it is trivial to deduce that either the programmer mistakenly
defined the Zip code field to be string when it should have been an int or the input
json received was invalid.  In practice, json objects are much larger and more complex. 
Determining which field of the hundreds in the message caused the unmarshaller to choke
is time consuming and painful.  The task could be made much easier if the field name
were displayed as part of the error message making it easier to track down bugs.

[adg]

Comment 1:

Agree this would be nice.
Made slightly inconvenient to implement because by the time the error is generated the
decoder is looking at the field value itself, not the struct that contains the field.
The relevant code doesn't even know that it's decoding into a struct field. There are a
few ways to get around this but they are non-trivial.

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

[rsc]

Comment 2:

Labels changed: added go1.3maybe.

[rsc]

Comment 3:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 4:

Labels changed: added repo-main.

[h4ck3rm1k3]

I have a patch for at least on level of code in #10134 would really want to store the entire stack and report on it. Could just append to the key string and make it longer each time when recursion happens.

[gopherbot]

CL https://golang.org/cl/18692 mentions this issue.

[rsc]

Fixing this is fine as long as the additional tracking does not slow down the common case (for example, the additional tracking can't allocate extra data for successful parses). The CL needs to be reviewed with that in mind, and possibly updated.

[ganelon13]

And what about time.Time in structure field? https://play.golang.org/p/YnlDi-3DMP

I got parsing time ""05.08.2017"" as ""2006-01-02T15:04:05Z07:00"": cannot parse "8.2017"" as "2006", where is Message.Created in error?

[nathany]

@ganelon13 Commenting on closed issues often doesn't get a response. Times in JSON should be in RFC3339 format.

[ganelon13]

@nathany Yes, I know this, thank you. But I want the field name in the error message

[nathany]

@ganelon13 Oh, now I understand. Good call.

I would suggest opening a new issue specifically for that with a reference to this issue #6716.

verified it's still an issue on master:

❯ gotip run j.go 
panic: parsing time ""05.08.2017"" as ""2006-01-02T15:04:05Z07:00"": cannot parse "8.2017"" as "2006"

[jwatte]

I was complaining about this error message:
json: cannot unmarshal string into Go value of type map[string]interface {}
It's a 5000 line document, where is the error?

However, this turns out to probably be a bug in the go-protoc generated code for protobufs, rather than go json itself.
Nothing to see in this particular thread, move on!