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: include field name in unmarshal error messages #6716

Closed
gopherbot opened this issue Nov 4, 2013 · 12 comments

Comments

Projects
None yet
8 participants
@gopherbot
Copy link

commented Nov 4, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

Comment 2:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 3:

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

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 4:

Labels changed: added repo-main.

@h4ck3rm1k3

This comment has been minimized.

Copy link

commented Mar 12, 2015

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

This comment has been minimized.

Copy link
Author

commented Jan 18, 2016

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

@bradfitz bradfitz modified the milestones: Go1.8Early, Unplanned May 11, 2016

@rsc

This comment has been minimized.

Copy link
Contributor

commented Sep 26, 2016

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.

@rsc rsc added the NeedsFix label Sep 26, 2016

@rsc rsc modified the milestones: Go1.8, Go1.8Early Sep 26, 2016

@gopherbot gopherbot closed this in b9fd510 Oct 5, 2016

@ganelon13

This comment has been minimized.

Copy link

commented Aug 5, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Nov 17, 2017

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

@ganelon13

This comment has been minimized.

Copy link

commented Nov 17, 2017

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

@nathany

This comment has been minimized.

Copy link
Contributor

commented Nov 17, 2017

@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

This comment has been minimized.

Copy link

commented May 31, 2018

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!

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