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: second decode after error impossible #31701

Open
lr1980 opened this issue Apr 26, 2019 · 4 comments
Open

encoding/json: second decode after error impossible #31701

lr1980 opened this issue Apr 26, 2019 · 4 comments
Labels
FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@lr1980
Copy link

lr1980 commented Apr 26, 2019

What version of Go are you using (go version)?

$ go version
go version go1.12.4 darwin/amd64

Does this issue reproduce with the latest release?

yes

What did you do?

Read a byte stream with multiple JSON's. The first has a syntax error.

What did you expect to see?

I expected "Decode" to save the position and continue working after the error. Without a syntax error, it works as expected...

What did you see instead?

It's impossible to decode a second time after a error, e.g.:
https://play.golang.org/p/0Z-lz_Wj9D7

@mvdan
Copy link
Member

mvdan commented Apr 27, 2019

SyntaxError gives you an offset, so you could re-start the decoder if you want that behavior. I'm not convinced that all encoding/json users would want the decoder to skip past syntax errors.

@lr1980
Copy link
Author

lr1980 commented Apr 27, 2019

Yes you are right! But it only works on a very inelegant way:
https://play.golang.org/p/XDva7S-Eg28

@mvdan
Copy link
Member

mvdan commented Apr 28, 2019

Agreed that it's inelegant, but is this really a common use case for the json package? I've used the package for many things over the last five years, and never have I needed to skip a syntax error and keep decoding some input.

This seems like a feature request or proposal to me, so it should be backed by some evidence to show that it's needed and useful in many cases. If not, having the user write a bit of extra code for the rare cases where one needs this specific behavior seems fine to me.

@lr1980
Copy link
Author

lr1980 commented Apr 28, 2019

Imagine you are reading data from a UDP stream. There it is absolutely possible that a JSON is broken, but I want to read on. The "Decoder" have all information to do that...

Yes it's absolutely a feature request. I could not find a better place for it...

@katiehockman katiehockman added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. Proposal FeatureRequest and removed NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Apr 30, 2019
@mvdan mvdan removed the Proposal label Nov 24, 2020
@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 30, 2020
@dmitshur dmitshur added this to the Backlog milestone Nov 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants