encoding/json: SyntaxError message change breaks brittle tests

[dsnet]

The change for #36221 adds a json: prefix to SyntaxError, which breaks >50 targets for the regression tests we run inside Google.

Thoughts:

• Relying on the error message is to rely on unspecified behavior and is generally considered outside the Go 1 compatibility promise. The json package theoretically has the right to change error messages.
• At the same time 50 targets is a non-trivial number of breakages. Fortunately they are all test failures (from my high-level glance).
• If we're going to cause churn with a changed error message, should we also consider whether SyntaxError.Offset should be part of the error message string? Why or why not?
• Should we batch changes like this for the future where we may want to introduce other changes to json that are technically compliant with the Go 1 compatibility promise, but may be slightly disruptive? Presumably it's better to break brittle targets once, rather than repeatedly.

Filing this issue to decide whether we're sure we want to move forward with this change.

\cc @mvdan @kevinburke @rsc

[mvdan]

Presumably it's better to break brittle targets once, rather than repeatedly.

I agree. Do we have more suggestions, though?

whether SyntaxError.Offset should be part of the error message string?

That could be a good idea, but how would you render it in the string? If you use ${offset}: ${message}, I think most people will incorrectly read the number as a line number and not a byte offset. We could go for ${message} at byte offset ${offset}, but it feels too wordy.

Another reason not to do it is that, right now, Error() is the only way to obtain just the message string. It might need to be coupled with exporting the msg string field.

At the same time 50 targets is a non-trivial number of breakages.

At this point I've learned to not try to argue with test breakages :)

[kevinburke]

Yikes. I did try to search on Github for code snippets that this change could break, but that search wasn't exhaustive and probably Google writes better tests.

I think backing this change out is the right thing to do.

[neild]

To be clear, these tests are brittle and shouldn't depend on the exact text of stdlib errors. We're fine with dealing with it internally. However, 50 tests is more than we usually see break from a changed error message, which might point at this having more impact than expected in the ecosystem at large.

[gopherbot]

Change https://golang.org/cl/273747 mentions this issue: encoding/json: revert "add "json: " prefix to SyntaxError messages"

[rsc]

Looking at things like the mod_proxy_invalid.txt message, I think leaving the prefix out makes a lot of sense. Let's just revert it please. What's done is done.

[kevinburke]

I think leaving the prefix out makes a lot of sense

A bigger discussion, I guess, but if it doesn't make sense to prepend the package name prefix in this case, I'm wondering why we have this convention in the standard library at all. I've noticed it's funky to expose Go errors to frontend clients in a browser UI context.