Future of pkg/errors after proposal ? #202

Activity

1. davecheney commented on Apr 12, 2019

   

   davecheney

   on Apr 12, 2019 via email

   Member

   More actions

   I expect this package will move into maintained mode.

   …

   On 13 Apr 2019, at 00:09, Wilk ***@***.***> 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.

   👍React with 👍1Reacted by Leigh

   😕React with 😕5Reacted by Ben Schumacher, Paul Tötterman, Daniel Cormier, Tariq and Michael Fridman
2. flibustenet commented on Apr 29, 2019

   

   flibustenet

   on Apr 29, 2019

   Author

   More actions

   If there is no wrap function in the proposal, i believe this lib should continue to live.
   golang/go#29934

   👍React with 👍3Reacted by brunetto, Knut Ahlers and Daniel Cormier
3. flibustenet commented on May 1, 2019

   

   flibustenet

   on May 1, 2019

   Author

   More actions

   golang/go#29934 (comment)

   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 ?

   👍React with 👍17Reacted by Mike Sun, Simon Rozet, brunetto, Przemysław Węgrzyn, Eddie Huang, Ben Schumacher, Daniel Cormier, Jay Petacat, Jonathan Hall, Bartlomiej Plotka and 7 more
4. inoc603 commented on May 14, 2019

   

   inoc603

   on May 14, 2019

   More actions

   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?
5. davecheney commented on May 14, 2019

   

   davecheney

   on May 14, 2019

   Member

   More actions

   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.

   👍React with 👍3Reacted by Leigh, a-urth and Takuma Ishikawa

   😕React with 😕6Reacted by Ben Schumacher, Eddie, Paul Tötterman, Daniel Cormier, Pavel Prishchepa and Maxim Vladimirskiy
6. ccpost commented on May 26, 2019

   

   ccpost

   on May 26, 2019

   More actions

   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: golang/go#29934 (comment)

   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.

   👍React with 👍6Reacted by Ben Schumacher, Benedikt Müssig, Kishan B, Willi Schinmeyer, Daniel Cormier and Wilk
7. jayschwa commented on Jul 3, 2019

   

   jayschwa

   on Jul 3, 2019

   Contributor

   More actions

   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.

   👍React with 👍10Reacted by Raphael Poss, Chris Post, Kishan B, Tomáš Karela Procházka, Knut Ahlers, Paul Tötterman, Daniel Cormier, Andrew Luzin, Borys Hulii and Kemal Akkoyun
8. ptman commented on Sep 4, 2019

   

   ptman

   on Sep 4, 2019

   More actions

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

   👍React with 👍9Reacted by Daniel Cormier, henribru, Borys Hulii, Bartlomiej Plotka, Jack Whelpton, kiennguyentiki, Naser Mirzaei, Maxim Vladimirskiy and Michael Fridman
9. james-johnston-thumbtack commented on Nov 13, 2019

   

   james-johnston-thumbtack

   on Nov 13, 2019

   More actions

   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 7f95ac1 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.

   👍React with 👍9Reacted by David Bariod, Maxim Vladimirskiy, Derrick J. Wippler, Ali Farooq, Ben Schumacher, Joel Courtney, rayjlinden, Ilai Fallach and Bartek Pacia
10. flibustenet commented on Nov 29, 2019

    

    flibustenet

    on Nov 29, 2019

    Author

    More actions

    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.

    👍React with 👍6Reacted by Fabian Holler, ᴊᴏᴇ ᴄʜᴇɴ, pymq, Bartek Pacia, Deepak Bhatt and curryshih
11. flibustenet

    closed this as completedon Aug 10, 2020