It's a linter that checks whether the returned error is the same one that was checked in the condition.
Due to the fuzzy nature of error handling in Golang, the linter has to employ certain heuristics to reduce the amount of false-positives. If you encounter obvious false-positives (or false-negatives), feel free to open an issue.
The linter, as it turned out, is quite similar to nilnesserr and seems to find a lot of the same problems, however, both linters detect some mistakes that the other one fails to identify.
For more examples, see the err_mistakes.go file which is used in automated testing.
if txErr != nil {
return err // will be reported
}if txErr := doSmth(); txErr != nil {
return err // will be reported
}if err != nil {
return fmt.Errorf("error: %w", anotherErr) // will be reported
}if err != nil {
return someCustomWrapper(someCustomError(anotherErr)) // will be reported
}if err != nil {
return errors.New("another") // creating an error on the spot is fine
}import "custom_errors"
if err != nil {
return custom_errors.SomeError // returning an error defined outside of the function's scope is fine
}go install github.com/m-ocean-it/correcterr/cmd/correcterr@latestThe same command will update the package on your machine.
correcterr [-flag] [package]To run on the whole project:
correcterr ./...All examples below are sufficient to disable a diagnostic on a specific line:
//nolint
//nolint:correcterr
//nolint:foo,correcterr,bar
//nolint:allMake sure not to add a space in front of nolint.
golangci-lint integration
correcterr is not likely to become a part of linters included in golangci-lint, however, I will, probably, implement a plugin to allow easy integration with golangci-lint "by hand".
- Formalize the principles on which the linter operates
- Implement a
golangci-lintplugin - Differentiate diagnostic messages based on specific cases
- Improve speed of execution