proposal: panic based error handling

[urandom2]

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:

• errors.Check
• errors.Handlef

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)

[ianlancetaylor]

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

[urandom2]

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

[dpinela]

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

[urandom2]

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]

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.

[rsc]

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.

[carnott-snap]

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]

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

[rsc]

There's no change in consensus, so declining.