errors
errors copied to clipboard
pkg
#75 Wrap() add withStack only if no cause with stack present
This apply feature suggested by #75.
Wrap() and Wrapf() now only add withStack when there are no stack captured before in error chain. The stack can still be forced via WithStack().
The test fail because this will change the behavior of "%+v" but I don't think I should mess with _test.go so I commit as is.
Yes please! I don't want to have to figure out if an incoming error has a stacktrace yet or not. I just want to ensure it has one.... but I definitely don't want to add another stack trace on top of the original one, since this is often a mostly duplicated stack trace (i.e. one level up).
Copying my comment here for people to see. This isn't an ideal solution but it works well enough:
Came to this thread with the same issue everyone else is having. This is how I solved it without forking this package or requiring additional dependencies. https://github.com/abraithwaite/go-examples/blob/master/errdive.go#L9-L30 You don't get the extra messages, but if you have the stack do you really need those?
Could this use a technique similar to causer.Cause with assertion for stackTracer? i.e.:
func isStackTracer(err error) (ok bool) {
if err == nil { return }
if _, ok = err.(stackTracer); ok {
return
}
if cause, ok := err.(causer); ok {
return isStackTracer(cause.Cause())
}
return
}
This change is problematic because it changes backwards compatibility and somebody else actually wants it this way. On our fork of pkg/errors we added new functions Annotate/Annotatef and consider Wrap/Wrapf deprecated.
Any news? It is not good to maintain own fork of this awesome package only because of this issue.
@develar this is one of several issues addressed in our fork. In this case, the forks are interoperable: one package can use pkg/errors and another package can use pingcap/errors. If you don't want the little bit of code bloat you can tell your package tool to use pingcap/errors as pkg/errors in your project. This does mean that pingcap/errors has to continue tracking any changes in pkg/errors, but that has been easy so far since there haven't been any.
Actually, thinking about this more, I have seen problems with the same interfaces defined in different packages. I would need to test to verify that you don't lose stack depth when using both packages and not replacing pkg/errors with pingcap/errors.
