errors: how should formatting be handled? #35929
I am concerned about two omissions:
My ultimate concern is that the go1.13 errors changes, particularly
My questions to the Go 2 review meeting are:
Full disclosure, I have raised this concerns before in the official proposal issue and my own counter-proposal (and am grateful for the time go team members did spend on them), but I failed to highlight these concerns with sufficient clarity.
The text was updated successfully, but these errors were encountered:
It would be nice to figure out some form of improvements to formatting error chains. Any such improvements cannot be a breaking change. We do not have any specific proposals on the table at this time.
Errors have a user-facing component (the string returned by the
To address the specific questions (although I'm not the review meeting, and have no official status here):
Breaking changes are clearly the biggest concern. I'll expand on those.
I'll use a basic example: say there is an error chain of 4 errors, with
Which brings me to my point about the breaking change: whatever new functionality is added to errors to support fomatting, it is not optional for wrapping errors. All errors implementing the new go1.13
So my question is:
Luckily, the interface was not named so hopefully it's adoption is limited, and those using it via golang.org/x/xerrors are using an experimental package and as such should tolerate breaking changes. But it still highlights my point that if we are to change it at all, better sooner than later.
I should list, for completeness, that the other option is to rely (and make part of the contract) that