Note: the scope of this issue has tightened, see https://github.com/pkg/errors/issues/15#issuecomment-217587756

This is an issue for discussion of a potential MutliError (or other name...) type API that allows the accumulation of multiple errors in a collection which still implements the error interface but allows retrieval of the individual errors.

There are a few other options out there: https://godoc.org/?q=multierror but since github.com/pkg/errors already implements, in my opinion, the canonical best practices for error handling in Go it would be be nice if it included this feature.

Hello,

In the services that we run we utilise json logging for all of our error logs, I had a peruse and it seems that the current print functions either require a writer or go straight to os.Stderr.

I think it would be very helpful for us, as well as for other users of this package, if there was a function that performs the same as fprint but returns a string for use.

I've created a proof of concept here: https://github.com/jimah/errors/blob/master/errors.go#L253

For example output please see the tests.

Thank you for your time!

Go 1.13 adds support for error chains to the standard libary's errors package. The new standard library functions require an Unwrap method to be provided by an error type. This change adds a new Unwrap method (identical to the existing Cause method) to the unexported error types.

In many cases when we're generating an error we know that the particular error, if it happens, is indicative of a bug. In those cases, it's very useful if the error message contains more information (like file:line).

Errors might be handled at a different layer (e.g. sent out to a client using %s) where the original context of the error is lost.

The proposal is to add a version of Errorf which results in a "verbose" error which automatically includes the file:line where it was generated as part of the error message.

I ran into an ugly bug today where I accidentally did this:

err := stuff()
if err != nil {
  return err
}
result := moreStuff()
if len(result.Failures) > 0 {
  // ... do stuff with failures ...
  return errors.Wrap(err, "Oops")
}

This returns nil because err is nil. The code wanted to make a new err, but it didn't. Due to Go's error conventions, you tend to have a single shared err shared across nested scopes like this, and one has to be careful about what it contains. It took me 10 minutes to realize that err was nil here.

In my opinion, Wrap(nil) should panic, because it makes no sense. The intent of the caller is clearly to wrap an error value (you shouldn't call Wrap if you don't have an error value), and you're telling it to wrap something that doesn't exist. I don't think this is controversial, but I think that, at best, it should return a new error with a nil cause.

I can see an opposite argument that "blanket wrapping" allowed:

return errors.Wrap(doStuff(), "it failed")

However, I think that's a special cause that ought to be relegated to something like MaybeWrap().

I just came across this package and wondering why package's Cause() function returns the root cause and not just the cause of the passed error value? I can imagine a situation where I want to inspect the cause of the error and check for some additional information in it, etc. So, to get that information I'll have to do a check for Cause() presence myself, call it, do a type check for additional information methods and only then call them. An additional method that returns the cause might be useful here.

ps. I wonder why this is not part of the standard library. Seems to be a very useful pattern.

It would be nice if we could have a aggregate error struc for handling and propagating multiple errors. Internally it would have a list of errors, which can be appended. This struct has only to implement the Error() interface in order to be a error. The following signatures could be supported:

  Append(err error)  // in order to append errors to the aggregate
  Count() int   // in order to provide a way to check if errors exist
  Error() string  // in order to implement the Error interface

Hello,

What do you think of errors' contexts like net/context or simple map[string]interface{} stored with the original error? It would be really handy; example:

var ErrNotFound = error.New("Page not found!")
...

return errors.Wrap(ErrNotFound,pageTitle).WithContext(`http`,404)

this way the imaginary http handler won't need to know about ErrNotFound; it would just grab the value from the context. It could be even better:

var ErrNotFound = errors.Wrap(error.New("Page not found!"),"").WithContext(`http`,404)
...
return errors.Wrap(ErrNotFound,pageTitle)

however, this approach would lose stack data; it would require the stored stack's reset.

The context or map can be initiated on demand (when adding first value), so it wouldn't create some significant overhead if context is not used.

Hello,

after merging #215, I got some test failures of code that calls errors.Cause(err) where err is returned by some stdlib API: in my case err is returned by net.Conn.Write(), and errors.Cause(err) used to return a net.OpError instance, whereas it now returns a syscall.Errno instance.

I understand the reason for the change, but just wanting to highlight this is introduces backward-incompatible behavior, at least for some consumers.

YMMV re fixing this issue. Other people might find it useful to read, if the stumble upon the same regression.

In #183 the definition of errors.Frame was altered to type Frame runtime.Frame. This was necessary because of the changes to mid stack inlining in Go 1.12 and the deprecation of runtime.FuncForPC.

https://go-review.googlesource.com/c/go/+/156364 suggests that it may be possible to continue to use runtime.FuncForPC. If this CL lands #183 should be mostly reverted for the 1.0 release.

A future v2 release would probably drop the use of runtime.FuncForPC and redeclare errors.Frame as an opaque struct.

How do you see the future of pkg/errors after the proposal for go1.13 ? https://go.googlesource.com/proposal/+/master/design/29934-error-values.md That will even works with older version of go https://godoc.org/golang.org/x/xerrors

Hello,

Quite clearly this package has been unmaintained for a long time. There are two main reasons for this (along with several others — waves in the general direction of life)

1. I had hoped that with the integration of some of the ideas from this package into Go 1.8 (I think) then the use of and need for this package would decrease. Sadly for whatever reason Go errors did not obtain the feature that this package was built for — stack traces on errors, so the need for this package remained.
2. I no longer use this package, in fact I no longer wrap errors. This sounds like a grandiose claim, and it may be my quirky coding style (my other views on error handling are hardly commonplace), so I don’t mean this comment to be a judgement on anyone who uses this package and enjoys it. It’s simply that it’s hard to make time to work on something which I no longer believe in.

Having got this off my chest, I recognise that this package holds a useful place in the Go ecosystem so it deserves more attention than it’s got over the last few years.

To that end, I welcome expressions of interest in the comments below.

Thank you

I expected Errorf to mimic fmt.Errorf's behavior of wrapping errors. Alas, that was not the case. I was wondering if this is intentional or not. If it's intentional, then is there a way of formatting wrapping errors as '(wrapped error): outer error'?

Here's a playground link explaining what I'm talking about. https://play.golang.org/p/yDjjs_8GsSY

I am currently considering using pkg/errors. However, I have a question, so I'm leaving a question.

I ran the example code and expected the output shown in the code comments. However, if you look at the output attached below, you can see that the output is completely different. The problem is that duplicate stacks are displayed.

And this also happens when I wrap the error passed to New() and WithStack(). Is this the intended behavior?

Environment: pkg/errors version: 0.9.1 Go version: 1.16 OS version: macOS Big Sur 11.0.1

My output:

error
main.fn
        /Users/choedongcheol/Workspace/temp/test/main.go:100
main.ExampleWrap_extended
        /Users/choedongcheol/Workspace/temp/test/main.go:116
main.main
        /Users/choedongcheol/Workspace/temp/test/main.go:208
runtime.main
        /Users/choedongcheol/.gvm/gos/go1.16/src/runtime/proc.go:225
runtime.goexit
        /Users/choedongcheol/.gvm/gos/go1.16/src/runtime/asm_amd64.s:1371
inner
main.fn
        /Users/choedongcheol/Workspace/temp/test/main.go:101
main.ExampleWrap_extended
        /Users/choedongcheol/Workspace/temp/test/main.go:116
main.main
        /Users/choedongcheol/Workspace/temp/test/main.go:208
runtime.main
        /Users/choedongcheol/.gvm/gos/go1.16/src/runtime/proc.go:225
runtime.goexit
        /Users/choedongcheol/.gvm/gos/go1.16/src/runtime/asm_amd64.s:1371
middle
main.fn
        /Users/choedongcheol/Workspace/temp/test/main.go:102
main.ExampleWrap_extended
        /Users/choedongcheol/Workspace/temp/test/main.go:116
main.main
        /Users/choedongcheol/Workspace/temp/test/main.go:208
runtime.main
        /Users/choedongcheol/.gvm/gos/go1.16/src/runtime/proc.go:225
runtime.goexit
        /Users/choedongcheol/.gvm/gos/go1.16/src/runtime/asm_amd64.s:1371
outer
main.fn
        /Users/choedongcheol/Workspace/temp/test/main.go:103
main.ExampleWrap_extended
        /Users/choedongcheol/Workspace/temp/test/main.go:116
main.main
        /Users/choedongcheol/Workspace/temp/test/main.go:208
runtime.main
        /Users/choedongcheol/.gvm/gos/go1.16/src/runtime/proc.go:225
runtime.goexit
        /Users/choedongcheol/.gvm/gos/go1.16/src/runtime/asm_amd64.s:1371

Hi, I see that the callers in the source code return *stack instead of stack. Why does this happen?

func callers() *stack {
	const depth = 32
	var pcs [depth]uintptr
	n := runtime.Callers(3, pcs[:])
	var st stack = pcs[0:n]
	return &st
}

https://github.com/pkg/errors/blob/614d223910a179a466c1767a985424175c39b465/errors.go#L244

how can i change format return error message, to this

func (w *withMessage) Error() string { return w.cause.Error()+ " | " + w.msg }