Often, errors require parameters, e.g.:

return nil, fmt.Errorf("unknown storage provider '%s'", providerName)

These aren't errors that need a statically/globally defined type, nor is there an error available which we can wrap. Both errors.New and fmt.Errorf report errors with err113, but there isn't a clear way to resolve them. Should the error be reported, if we're not passing an error typed parameter for %w?

How to make panic errors wrapped static

if rec := recover(); rec != nil {
	trace := debug.Stack()

	err = fmt.Errorf("PANIC [%v] TRACE[%s]", rec, string(trace))
}

linter error

err113: do not define dynamic errors, use wrapped static errors instead: "fmt.Errorf(\"PANIC [%v] TRACE[%s]\", rec, string(trace))"

The documentation explicitly states:

Note: non-standard packages, like github.com/pkg/errors are ignored complitely.

However, if I write the following code:

package main

import (
	"fmt"

	"github.com/pkg/errors"
)

func main() {
	err := errors.New("option failed")
	fmt.Println(err)
}

and execute err113 ., I see:

C:\Projects\localhost\tst\main.go:10:9: do not define dynamic errors, use wrapped static errors instead: "errors.New(\"option failed\")"

It would be nice if this linter could also detect issues with asserting errors to specific types, this is common in AWS sdk (as well as many places): https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/handling-errors.html

if awsErr, ok := err.(awserr.Error); ok {

While running go-err113 with -fix flag, I got weird replacement, some can be listed as below:

err == http.ErrServerClosed -> errors.Is(err, &{http ErrServerClosed})
ctx.Err() == context.DeadlineExceeded -> errors.Is(&{%!s(*ast.SelectorExpr=&{0xc005394f00 0xc005394f20}) %!s(token.Pos=67939731) [] %!s(token.Pos=0) %!s(token.Pos=67939732)}, &{context DeadlineExceeded})

Hello!

Go 1.13 provides a mechanism for wrapping through %w, but this does not mean that now you can refuse libraries like https://github.com/pkg/errors, which provides a more convenient api for working with errors.

Also this absolutely does not mean that you should use errors.Is() everywhere instead of == (adding yourself an overhead for recursion). It all depends on the context of the program.

Is there anywhere documented evidence that this is how errors should be handled?

Nowtime it looks like a very crude idea for linter.

Hello!

At the moment, in golangci-lint, we have two linters that perform the same functionality.

Your linter appeared later, but it seems to have more options.

I would suggest:

1. Implement errors.As (#14)
2. Make exceptions / flags for dynamic errors (#10)
3. As a request from me: to require the creation of an error through the error.New if there are no formatting arguments:

var MyError  = fmt.Errorf("some error")

4. Support type switches.

And then that go-errorlint can be asked to archive :)

What do you think? If you do not mind the points above, I can try to find the time and help you implement them.

Greetings and thanks for the linter.

The linter doesn't seem to like the following code:

func testingSubroutine(i1 int, i2 int) error {
    if i1 != i2 {
        return errors.New("i1 and i2 are not equal!")
    }

    return nil
}

It gives the error:

err113: do not define dynamic errors, use wrapped static errors instead

However, this seems nonsensical, because there is nothing to wrap. I'm just creating a brand new error. Is this a bug in the linter or am I misunderstanding the error message?