Rip out all usage of github.com/pkg/errors

[LandonTClipp]

Description

This package has been deprecated and archived, we should not use it anymore. Replace all instances of pkg/errors with the golang-standard packages. Use the %w wrapping directive from fmt.Errorf to add contextual information to errors.

pkg/errors#245

[amirkhaki]

What about printing stacktrace?
https://github.com/vektra/mockery/blob/1c1eeea67b69fb8a9c945d6e5541e8449315c62b/cmd/mockery.go#LL42C1-L42C1

[LandonTClipp]

I think we'll have to accept not having stack traces anymore :'(

I'm disappointed that the functionality proposed in pkg/errors was not accepted in the stdlib, and I would have continued using pkg/errors had it not been archive, but c'est la vie 🤷🏻

[sruehl]

I would vote to keep it. Is there a reason at the moment not to use it? Sure it is archived but on the other hand pretty light weight. So maybe Go2 will support for stack traces.

[LandonTClipp]

IMO we shouldn't use things that are archived. I was considering just forking the project but I want to be careful with committing myself to too many things. If someone picks it back up then we should continue to use it... the standard errors library is inferior to pkgs/errors.

[LandonTClipp]

On second thought, I'm trying to contact @davecheney to see if he will let me take over maintainership.

[scraymondjr]

@LandonTClipp just curious, what is the harm of using an archived project, especially with Go's backwards compatibility guarantees?

[LandonTClipp]

@scraymondjr it's the lack of maintenance support if something were to become non-functioning (it happens sometimes). It's true anyway that the standard errors package provides the error wrapping semantics that pkg/errors gives us. The stack tracing though is still not something the std lib provides.

I'll defer this for a bit. I did fork pkg/errors to my own org at https://github.com/chigopher/errors, but I might want to rip out the wrapping logic and instead preserve the stack tracing.

[wolfeidau]

Not sure if you had seen it but I have been using https://github.com/pingcap/errors as they have done quite a bit work in their fork to update / upgrade to support their own projects.

I use this version for some of my projects.

[cszczepaniak]

Two cents from a user: it would be nice to not take on a transitive dependency on a public archive especially for something that is mostly subsumed now by the Go standard library. I don't love using things like Is and As from a public archive when they exist in the stdlib now.

As for stack traces, is there a reason not to just use debug.Stack and a thin error wrapper internal to this project instead of taking on a third party dependency for it? It's not that much code.

type stackErr struct {
    cause error
    stack []byte
}

func NewStackErr(cause error) stackErr {
    return stackErr{
        cause: cause,
        stack: debug.Stack(),
    }
}

func (e stackErr) Error() string {
    return e.cause.Error()
}

func (e stackErr) Unwrap() error {
    return e.cause
}