go: errors: ensure the 1.13 method to access the cause is called Cause() not Unwrap()

It is not a goal of the proposal to be compatible with existing error packages. Indeed, that is impossible, since they contradict each other. The goal is to establish a common set of names and behaviors, and the hope is that existing packages like pkg/errors will adopt them.

How is the program now meant to identify the ultimate cause of its error?

Couldn’t you continue to use Cause? Leaving aside the fact that you should never wrap io.EOF, you could write

if pkgerrors.Cause(err) == io.EOF || xerrors.Is(err, io.EOF) { ... }

You are mistaken: play.golang.org/p/1rR97pPojOd

Thank you for the example, although I believe it is disingenuous: this exemplifies specifically the feature of that package that hides the cause. The goal of that Note API is to provide control for the code that constructs the error on the ability for other downstream code to query that cause. That use case / requirement would exist also for users of xerrors and arguably an xerror-compatible implementation could provide the same feature that prevents a cause from being visible via Unwrap().

So far it does not seem you have provided evidence that in the common case (even a common case for gopkg.in/errgo.v2/errors) the established ecosystem is incompatible with the Go 1.13 proposal, and it does not seem that the conversation so far has provided a reason to keep the current design that outweighs the inconvenience that I have outlined initially.

No that will fail if an error is wrapped both by xerrors and pkgerrors. You could instead write your own function, looking for both Cause and Unwrap methods.

Yes I am aware I could do this. However, if I and other people find ourselves required to do this often (as I am arguing since the beginning of the thread), this would be strong evidence that the proposed definition of Go’s error API is defective. Now (before 1.13 is released) would be an adequate time to study this risk and perhaps make adjustments before the Go user community finds themselves inconvenienced by the defect.

You realize that you could change the go 1.14/xerror code to use Cause instead and take the cost of the change for yourself, instead of pushing it to the community right?

So far the discussion has been pretty clear:

1. there’s no real good reason to keep Unwrap over Cause other than choosing who to inconvenience the most

2. in terms of number of people inconvenienced you are choosing the maximum amount of inconvenience because… I guess it makes someone’s life easier, consequences be dammed? – Sent from my Android device with K-9 Mail. Please excuse my brevity.

I would expect third party packages like github.com/pkg/errors to change their Cause function to support both their own Cause method and Unwrap. That seems like the way to migrate from github.com/pkg/errors to xerrors to Go1.14.

As a matter of practicality, golang.org/x/xerrors uses Unwrap(), and there are people using that package now. Which means that whether we end up choosing Unwrap() or Cause() or something else, everyone else is going to have to add backward compatibility,

If we choose Unwrap(), then github.com/pkg/errors and everyone else will have to add support for Unwrap().

If we choose Cause(), then golang.org/x/xerrors and everyone else will have to add support for Cause().

And ditto for any other API that is out there.

I understand that the error values proposal isn’t final yet, but I think it would be impractical to change it drastically without a strong reason since people are using it already (including me). Similarly, there was no guarantee that github.com/pkg/errors provided any kind of standard API across the Go ecosystem and their users should have understood that they were committing to an API only implemented by github.com/pkg/errors and any explicitly cooperating packages.

The point of this part of the error values proposal, as I see it, was to commit to a standard API across the Go ecosystem. That it is not the github.com/pkg/errors API is perhaps unfortunate, but at this point in time being noncommittal about the API will cause more harm than benefit.

Addressing @knz’s concern directly,

Suppose a program upgrades to use Go 1.13 but has some dependency library that relies on github.com/pkg/errors (or another Cause()-compatible error library). Now consider what happens if our program makes some API call through its dependency, and that encounters an error from the standard library – for example io.EOF or context.DeadlineExceeded. And then the intermediate library dependency wraps the error using the facilities in github.com/pkg/errors which only provides Cause().

How is the program now meant to identify the ultimate cause of its error?

• If your program previously used Cause style functions to check errors, it will keep working.
• If you switched your program to use Unwrap style functions on a library that doesn’t support it, well, don’t do that.
• If the library adds support for Unwrap style errors (which is trivial), then you are free to to switch to using Unwrap style functions or keep using Cause style functions.

The error values proposal doesn’t change the fact that every package needs to document an explicit contract about how a user will go about unwrapping or checking errors, or the backward compatibility implications thereof. All it does is adds a standard contract that hopefully all packages can agree upon going forward.

Our final decision is to stay with Unwrap.

@knz please be respectful.

why/how?

There exist error implementations where the Cause method returns the root of the chain, as well as ones where Cause returns the next step in the chain. There is no way to reconcile these two definitions.

Was this issue a reason for revert at 3e2c522d5c712fa2b1d18a101272abefc7dcb074?

Edit after @jba’s answer below. Found it: https://github.com/golang/go/issues/29934#issuecomment-489682919

As a matter of practicality, golang.org/x/xerrors uses Unwrap(), and there are people using that package now. Which means that whether we end up choosing Unwrap() or Cause() or something else, everyone else is going to have to add backward compatibility

I am really glad that you recognize that some people are going to be inconvenienced.

It would be interesting here, for the sake of clarity and methodology, to estimate the size of the user populations. AFAIK xerrors has been around for less time than the alternatives using Cause().

There is a utility argument to be made about the amount of inconvenience. A solution that causes less inconvenience in aggregate seems (to me) to be the better solution. I am sure that the fact that you happen to be invested in the initial development of xerrors will not bias you against looking at the utility aspect as a whole.

I went and looked at the package you linked, and I am afraid the source code contradicts your statements:

You are mistaken: https://play.golang.org/p/1rR97pPojOd