Future of pkg/errors after proposal ?

flibustenet commented 5 years ago

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

davecheney commented 5 years ago

I expect this package will move into maintained mode.

On 13 Apr 2019, at 00:09, Wilk notifications@github.com wrote:

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

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

flibustenet commented 5 years ago

If there is no wrap function in the proposal, i believe this lib should continue to live. https://github.com/golang/go/issues/29934

flibustenet commented 5 years ago

https://github.com/golang/go/issues/29934#issuecomment-488145630

Existing package, like pkg/errors, can implement its interfaces so errors become introspectable and legible, when printing, across error types. The goals was not to come up with a new such package per se. The changes to errors.New and fmt.Errorf were not intended as a new API to replace them all, but as a way to make old code produce errors that interoperate well.

pkg/errors could evolve to become compatible with the new proposal ?

inoc603 commented 5 years ago

It seems to me adding Unwrap to fundamental can make pkg/errors compatible with the new proposal. Is there anything that might break if we introduce this change?

davecheney commented 5 years ago

Thank you for raising this issue. I don't have the time to answer in full but the short, and final answer, is this package will be in maintenance once Go 1.13 ships.

ccpost commented 5 years ago

For those coming here who may not have dug through the entire proposal thread, it seems that the final surface of changes in Go 1.13 will be much smaller than the original proposal: https://github.com/golang/go/issues/29934#issuecomment-489682919

In particular, it removed all support for constructing / wrapping errors with any stack / frame information, so it seems the only functionality overlap between Go 1.13 and pkg/errors is the general concept of wrapping. In that case, it seems there will still be widespread desire for pkg/errors.

Separate from Go 1.13, I very-much understand the maintainer's decision to consider pkg/errors feature complete and focus on bug fixes only.

jayschwa commented 5 years ago

pkg/errors could evolve to become compatible with the new proposal ?

Pull request #206 adds support for the new standard library errors functions coming in Go 1.13.

ptman commented 5 years ago

Yes, stack/frame information is still a benefit over stdlib errors. Please keep providing this valuable feature.

james-johnston-thumbtack commented 4 years ago

I agree with many of the others here: the new Go 1.13 error wrapping is only a partial replacement for pkg/errors, and we still need to utilize pkg/errors for providing valuable stack trace information since that didn't make it into the Go runtime.

I understand the maintainer's desire to spend less time working on this package, but I hope a solution can be found that works well for augmenting Go 1.13 with support for stack traces. As such, I'd suggest:

Commit https://github.com/pkg/errors/commit/7f95ac13edff643b8ce5398b6ccab125f8a20c1a added Unwrap support to the error types, which is great!
For compatibility, please consider updating errors.Cause to support Unwrap interface as well as the existing "causer" interface.
Consider adding Is, As, and Unwrap functions to pkg/errors, which do the same things as in the errors package, but also support the "causer" interface (for compatibility reasons) in addition to Unwrap: some users have written custom error types that support only "causer" interface and may need time to migrate those. At the very least, forcing users to import two packages with the same name of "errors" is awkward since they have to be aliased. (And in our case, we established a linting rule banishing the import of the built-in "errors" package, since we'd rather people use the functionality of pkg/errors to ensure stack trace availability.)

Someday, if Go runtime ever supports stack traces on errors in a first-class fashion like they have done with error wrapping, then I could see the complete deprecation of this package. Otherwise, finding a way for it to play nice as much as possible would be really valuable.

flibustenet commented 4 years ago

If one want to jump directly in the new wagon, there is a tools to replace pkg/errors by fmt.Errorf safely: https://github.com/xdg-go/go-rewrap-errors (and an excellent article to explain how it works https://xdg.me/blog/rewriting-go-with-ast-transformation)

Finally for my projects i believe pkg/errors is now overkill. I found valuable to replace gradually pkg/errors by fmt.Errorf and add stacktrace myself just when needed. Again with help of a recent article: https://www.komu.engineer/blogs/golang-stacktrace/golang-stacktrace

Hope theses links help somebody else.

pkg / errors

Future of pkg/errors after proposal ? #202