proposal: Go 2: adopt Cause and Wrap from github.com/pkg/errors

[VojtechVitek]

Is there anyone else who'd like to see https://github.com/pkg/errors (or similar) being adopted in Go 2.0?

Forked from #21161 (comment).

Example:

func Chdir(dir string) error {
	if e := syscall.Chdir(dir); e != nil {
		return errors.Wrap(e, "failed to change directory")
	}
	return nil
}

Alternative one-liner example, since errors.Wrap() returns nil on nil error:

func Chdir(dir string) error {
	return errors.Wrap(syscall.Chdir(dir), "failed to change directory")
}

[VojtechVitek]

I think we could simplify the https://github.com/pkg/errors API a little further and add two new functions only:

func Cause(err error) error
func Wrap(err error, message string) error
- func Errorf(format string, args ...interface{}) error
- func WithMessage(err error, message string) error
- func WithStack(err error) error
- func Wrapf(err error, format string, args ...interface{}) error

1. assuming the stack traces were configurable globally, ie. via a flag:

func main() {
	if debug {
		errors.CaptureStackTraces = true // false by default
	}
}

2. and if we kept using fmt package for formatted error messages (fmt.Errorf(), fmt.Wrapf()).

cc @bradfitz @davecheney

[VojtechVitek]

I think we could simplify the https://github.com/pkg/errors API a little further and add two new functions only:

func Cause(err error) error
func Wrap(err error, message string) error
- func Errorf(format string, args ...interface{}) error
- func WithMessage(err error, message string) error
- func WithStack(err error) error
- func Wrapf(err error, format string, args ...interface{}) error

1. assuming the stack traces were configurable globally, ie. via a flag:

func main() {
	if debug {
		errors.CaptureStackTraces = true // false by default
	}
}

2. and if we kept using fmt package for formatted error messages (fmt.Errorf(), fmt.Wrapf()).

cc @bradfitz @davecheney

[jellevandenhooff]

As another point in the design space, a package like https://github.com/pkg/errors but with the simpler API is https://godoc.org/github.com/samsarahq/go/oops.

[jellevandenhooff]

As another point in the design space, a package like https://github.com/pkg/errors but with the simpler API is https://godoc.org/github.com/samsarahq/go/oops.

[ianlancetaylor]

It's a good package, but what's the argument for bringing it into the standard library? Bear in mind https://golang.org/doc/faq#x_in_std .

[ianlancetaylor]

It's a good package, but what's the argument for bringing it into the standard library? Bear in mind https://golang.org/doc/faq#x_in_std .

[jellevandenhooff]

One motivation for standardizing is uniform handling of well-known errors. For example, wrapping io.EOF confuses io.Copy, which ignores io.EOF but not when wrapped since it checks for equality. I don't have a great answer on what to do though, because sometimes you might want a wrapped error to have a different semantic meaning and other times you might want to preserve the original error but just have some added debug information.

[jellevandenhooff]

One motivation for standardizing is uniform handling of well-known errors. For example, wrapping io.EOF confuses io.Copy, which ignores io.EOF but not when wrapped since it checks for equality. I don't have a great answer on what to do though, because sometimes you might want a wrapped error to have a different semantic meaning and other times you might want to preserve the original error but just have some added debug information.

[VojtechVitek]

@ianlancetaylor argument for bringing it into the standard library is just standardization of error context across the Go ecosystem. Not everyone uses github.com/pkg/errors as of now obviously.

Example:
I'd like to be able to inspect a stack trace of any incoming error from 3rd party pkgs. Currently, I struggle with some generic errors returned by vendored packages (ie. a variable instantiated during the boot time, returned by many functions/methods). I always end up debugging the underlying package itself (debugger or with injecting errors.Wrap()) instead of having a quick hint about the cause (file:line) in the first place.

[VojtechVitek]

@ianlancetaylor argument for bringing it into the standard library is just standardization of error context across the Go ecosystem. Not everyone uses github.com/pkg/errors as of now obviously.

Example:
I'd like to be able to inspect a stack trace of any incoming error from 3rd party pkgs. Currently, I struggle with some generic errors returned by vendored packages (ie. a variable instantiated during the boot time, returned by many functions/methods). I always end up debugging the underlying package itself (debugger or with injecting errors.Wrap()) instead of having a quick hint about the cause (file:line) in the first place.

[ianlancetaylor]

Thanks. Standardization of error context is a big concept, and I don't think that the errors package addresses all aspects of it. For example, see https://commandcenter.blogspot.com/2017/12/error-handling-in-upspin.html for some additional ideas in this space.

[ianlancetaylor]

Thanks. Standardization of error context is a big concept, and I don't think that the errors package addresses all aspects of it. For example, see https://commandcenter.blogspot.com/2017/12/error-handling-in-upspin.html for some additional ideas in this space.

[dsnet]

\cc @neild @mpvl

[dsnet]

\cc @neild @mpvl

[carlmjohnson]

I would also like to see standardization around some common optional interfaces, like IsTemporary() bool. Having it in the stdlib would encourage people to use the same interfaces when applicable.

[carlmjohnson]

I would also like to see standardization around some common optional interfaces, like IsTemporary() bool. Having it in the stdlib would encourage people to use the same interfaces when applicable.

[carlmjohnson]

I like the approach in this blog post, Failure Is Your Domain. The author emphasizes the importance of "owning" your failure modes, but I think that some of the functions mentioned in the article would be good candidates for standard library inclusion.

[carlmjohnson]

I like the approach in this blog post, Failure Is Your Domain. The author emphasizes the importance of "owning" your failure modes, but I think that some of the functions mentioned in the article would be good candidates for standard library inclusion.

[nezorflame]

I'd be glad to see standard errors package simply replaced by github.com/pkg/errors (or something with the same purpose), like it was mentioned here: #16968
Standard one doesn't give you anything which fmt.Errorf() doesn't do already.
Never understood why we have both fmt.Errorf() and errors.New() tbh, instead of doing errors.Newf() or fmt.Error().

[nezorflame]

I'd be glad to see standard errors package simply replaced by github.com/pkg/errors (or something with the same purpose), like it was mentioned here: #16968
Standard one doesn't give you anything which fmt.Errorf() doesn't do already.
Never understood why we have both fmt.Errorf() and errors.New() tbh, instead of doing errors.Newf() or fmt.Error().

[deanveloper]

Is there a reason why this is a Go 2 issue, rather than just including the new functions into the errors package? After all, it should be backwards compatible

[deanveloper]

Is there a reason why this is a Go 2 issue, rather than just including the new functions into the errors package? After all, it should be backwards compatible

[bradfitz]

@deanveloper, because Go isn't a language where we just keep adding stuff all the time. We prefer to think about the end goal and the minimal set of things that would interact well. Once we add stuff, we can't remove it soon or easily, and it might not be what we want in the end. So we prefer to go slowly, even if that's boring and frustrating at times.

[bradfitz]

@deanveloper, because Go isn't a language where we just keep adding stuff all the time. We prefer to think about the end goal and the minimal set of things that would interact well. Once we add stuff, we can't remove it soon or easily, and it might not be what we want in the end. So we prefer to go slowly, even if that's boring and frustrating at times.

[ianlancetaylor]

Closing in favor of the discussion at https://github.com/golang/go/wiki/Go2ErrorValuesFeedback . I have added this issue to that page.

[ianlancetaylor]

Closing in favor of the discussion at https://github.com/golang/go/wiki/Go2ErrorValuesFeedback . I have added this issue to that page.