3 ms·
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
by 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.
- pstuart 3y agoIt would be great if the internals added %W as an option that would also include the relevant trace. Shouldn't be unreasonable or impossible.
- Groxx 3y agoExcept 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 agoIt’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 agoWell, 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.
- tubthumper8 3y agoIt's been said that "Go" stands for "Go implement it yourself"
- arp242 3y agoMy implementation is about 120 lines, plus about 100 lines of tests. It's not hard, but not trivial either. Doing that for every single project is rather tedious. Especially for prototyping I just quickly want something that 'just works' without fuss.