6 ms·

Can you explain why we should this over https://github.com/pkg/errors https://github.com/pkg/errors?

• para_parolu 3y ago
  Even this package is not needed anymore
  • dagss 3y ago
    How do you get stack traces of errors?
    • randomdata 3y ago
      The same way you get stack traces of names, email addresses, random numbers, etc. It is funny how the word 'error' leaves some suddenly forgetting how to write software.
• abhinavg 3y ago
  The README covers the idea behind errtrace in more details, but the primary difference is in what is captured: pkg/errors captures a stack trace of when the error occurred, and attaches it to the error. This information doesn't change as the error moves through the program. errtrace captures a 'return trace'--every 'return' statement that the error passes through. This information is appended to at each return site. This gives you a different view of the code path: the stack trace is the path that led to the error, while the return trace is the path that the error took to get to the user. The difference is significant because in Go, errors are just plain values that you can store in a struct, pass between goroutines etc. When the error passes to another goroutine, the stack trace from the original goroutine can become less useful in debugging the root cause of the error. As an example, the Try it out section (https://github.com/bracesdev/errtrace/#try-it-out https://github.com/bracesdev/errtrace/#try-it-out) in the README includes an example of a semi-realistic program comparing the stack trace and the return trace for the same failure.
  • avg_dev 3y ago
    How does one go about implementing something like this? I am quite curious.
    • yalue 3y ago
      Judging by the project, it's implemented by instrumenting the source code; either manually modifying error returns with a wrapper function, or by running source files through an automated tool that will find and modify the return statements for you.
    • marhee 3y ago
      I suspect it is based on https://pkg.go.dev/runtime#Caller https://pkg.go.dev/runtime#Caller
• Groxx 3y ago
  At the very least: >This repository has been archived by the owner on Dec 1, 2021. It is now read-only. It's largely complete so it is essentially fine at the moment, but it won't be adapted to future language or community changes. A future landmine.
  • oefrha 3y ago
    It’s archived mainly because it’s been superseded by fmt.Errorf() with the %w directive. Go 1.20 also introduced errors.Join() and multi-%w which github.com/pkg/errors lack, so using for green field projects is very ill-advised.
    • Groxx 3y ago
      Except for the stack trace part, which is a gigantic reason why it was popular. tbh I'm not sure what the current popular option is for wrapping with stack traces. Re join: it isn't a joiner-error, it has no need to do anything for that. Just stdlib-join-then-wrap.
      • oefrha 3y ago
        It’s pretty easy to write your own Errorf() wrapper or some sort of WithStack() that stores runtime/debug.Stack() output. github.com/pkg/errors offers more flexibility in formatting though.
        • Groxx 3y ago
          Well, sure, but by that metric this library is even easier to build yourself since it's only gathering a single stack entry per wrap. And it has no backwards compatibility to worry about. "You can build X by hand too" has little to do with why people choose to create or use libraries.
          • healsdata 3y ago
            > "You can build X by hand too" has little to do with why people choose to create or use libraries. In my experience, "you can build X by hand" is the Go community's preferred approach.
• deleted 3y ago
  [deleted]