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

proposal: panic based error handling #36189

Closed
urandom2 opened this issue Dec 17, 2019 · 9 comments
Closed

proposal: panic based error handling #36189

urandom2 opened this issue Dec 17, 2019 · 9 comments

Comments

@urandom2
Copy link
Contributor

Since "there is really nothing wrong with using panic within a single package", as discussed in #35093, I thought I would use this to propose improving error handling. My apologies if this duplicates other proposals, and feel free to merge/close as appropriate.

I suggest adding two new functions to the errors package:

Because these primitives can be implemented in pure go1, I have built a sample implementation:

import "git.sr.ht/~urandom/errors"

func Set(v interface{}) (ret error) {
        defer errors.Handlef(&ret, "setting: %v", v)
        _, err := set(v)
        errors.Check(err)
        return nil
}

This is proposal borrows exact syntax heavily from the try proposal, however panic could be used differently:

package errors

func Check(ret *error, check error, msg string)
@gopherbot gopherbot added this to the Proposal milestone Dec 17, 2019
@ianlancetaylor
Copy link
Contributor

Make a go-gettable package with these functions and lets see how many people find them useful.

@urandom2
Copy link
Contributor Author

urandom2 commented Dec 18, 2019

I should have already done this: does go get git.sr.ht/~urandom/errors not work for you?

@dpinela
Copy link
Contributor

dpinela commented Dec 20, 2019

https://github.com/mpvl/errc implements a similar idea.

@urandom2
Copy link
Contributor Author

urandom2 commented Dec 22, 2019

https://github.com/mpvl/errc implements a similar idea.

I was not aware of this package, good find. I think there is still some bike shedding left to get an optimized interface, but panic opens up some options to implement this without changes to the language.

@carnott-snap
Copy link

Is any additional information required, or is this proposal on Hold, but not correctly labelled? It appears to have missed the past few proposal review meetings: #33502.

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals (old) Feb 5, 2020
@rsc
Copy link
Contributor

rsc commented Feb 5, 2020

This doesn't need to be in the standard library, and we've decided not to add more error handling changes for quite some time. Thanks for publishing the idea as a separate package others can already import.

This seems like a likely decline.

@rsc rsc moved this from Incoming to Likely Decline in Proposals (old) Feb 5, 2020
@carnott-snap
Copy link

carnott-snap commented Feb 5, 2020

This doesn't need to be in the standard library[.]

While I agree, the same could be said about errors.Is and errors.As. The conventions interface { Is(error) bool } and interface { As(interface) } do not need to live in the standard library. xerrors could have served us for many releases, until the community fully embraced that pattern. My goal for standard library inclusion is to promote the pattern, because it has been blessed as canonical, shares implementation details with try, and I am unsure how to better evangelise.

[W]e've decided not to add more error handling changes for quite some time.

I am sad to hear this because of how cumbersome error handling is in Go, but also confused by the distance from how I read the recent blog post. I think it would be helpful to convey your exact words to the community, as many are still motivated to improve the state of error handling in Go.

@ianlancetaylor
Copy link
Contributor

The next paragraph in that blog post says "with error handling changes out of the way for the time being".

@rsc
Copy link
Contributor

rsc commented Feb 12, 2020

There's no change in consensus, so declining.

@rsc rsc closed this as completed Feb 12, 2020
@rsc rsc moved this from Likely Decline to Declined in Proposals (old) Feb 12, 2020
@golang golang locked and limited conversation to collaborators Feb 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Development

No branches or pull requests

6 participants