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.

Sign up for GitHub

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

Jump to bottom

proposal: errors: change New to return a type that implements Is #48639

Closed
MovieStoreGuy opened this issue Sep 27, 2021 · 4 comments
Closed

proposal: errors: change New to return a type that implements Is #48639

MovieStoreGuy opened this issue Sep 27, 2021 · 4 comments
Labels
FrozenDueToAge Proposal
Projects
Proposals (old)
Milestone
Proposal

Comments

@MovieStoreGuy
Copy link

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

$ go version
go version go1.17.1 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

The issue arrises when trying to compare errors that have not be cached as part of the library.

if errros.New("foo") != errors.New("foo") {
   // Always executes branch as per the contract of errors.New
}

// Using go 1.13+ error handling
if errors.Is(errors.New("foo"), errors.New("foo")) {
   // Never executed even though they would appear to be the same error
}

What did you expect to see?

In order to keep compatibility with the existing contract provided by the errors package, I would expect the following:

if errors.New("foo") == errors.New("foo") {
  t.Errorf("Different allocation must not be equal")
}

if !errors.Is(errors.New("foo"), errors.New("foo") {
  t.Errorf("Errors made of the same message must be considered the same error")
}

What did you see instead?

Currently errors.New does not implement a means to compare the internally stored error message and requires libraries to define Errs as global variables that can be reassigned at runtime if not careful.
@gopherbot gopherbot added this to the Proposal milestone Sep 27, 2021
@ericlagergren
Copy link
Contributor

errors.New intentionally returns unique errors. My “foo” and your “foo” might have different meanings, and so the errors package would be wrong to declare them as equal.

As you noted, the idiomatic way to compare errors is to use a package-level variable or a custom error type.

@D-sense
Copy link

D-sense commented Sep 27, 2021

Hi @MovieStoreGuy, the detail provided by @ericlagergren is sufficient, I believe. You may want to use this approach: https://play.golang.org/p/VYXRW5Bp2Qr

@ianlancetaylor ianlancetaylor changed the title proposal: errors.New returned type to implement errors.Is proposal: errors: change New to return a type that implements Is Sep 27, 2021
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals (old) Sep 27, 2021
@MovieStoreGuy
Copy link
Author

With a heavy sigh I agree with you @ericlagergren, my frustration when those errors that would be important to capture and match aren't exposed in a means that is easy to do so (beyond string matching which is a different kettle of fish).

I really should argue for better practices in this libraries than trying to hack the src so to speak.

@rsc rsc moved this from Incoming to Declined in Proposals (old) Oct 6, 2021
@rsc
Copy link
Contributor

rsc commented Oct 6, 2021

This proposal has been declined as retracted.
— rsc for the proposal review group

@golang golang locked and limited conversation to collaborators Oct 6, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Proposal
Projects
No open projects
Proposals (old)
Declined
Milestone
Proposal
Development

No branches or pull requests
5 participants
@rsc @ericlagergren @gopherbot @D-sense @MovieStoreGuy