What does HackerNews think of errcheck?

Every Go project I've worked on has used this linter. I think it should be builtin, but it's very easy to incorporate.

We'll agree to disagree about unused imports; imports have can side-effects.

It doesn't though. It's not a warning or error to not use the return value of a function that only returns an error, for instance (https://go.dev/play/p/se6-zHHVezH).

There are static error checking tools you can use like https://github.com/kisielk/errcheck to work around this, but most people don't use them.

I've run into a lack of Go error checking many times. Many times it's just the trivial case, where the compiler doesn't warn about not checking the result of an error-returning function.

But often it'll be subtler, and the result of Go's API design. One example is its file writing API, which requires you to close the file and check its error to be correct. Many times people will just `defer file.Close()`, but that isn't good enough - you're ignoring the error there.

Worse still is e.g: writing to a file through a bufio.Writer. To be correct, you need to remember to flush the writer, check that error, then close the file and check that error. There's no type-level support to make sure you do that.

I think the reason they don't do this is that it's a slight (albeit a very tiny one) against Go's philosophy of errors being values, just like any other. While the `error` type is standard and used throughout Go source code, it still just has a simple three-line definition[3] and is not treated as a special case anywhere else; there is nothing stopping you from returning your own error type if you wish. A third-party linter could simply check for the `error` type specifically, but the first-party tools should not, and there's nothing like Rust's `#[must_use]` attribute that could be used instead. I respect Go's philosophy, but I feel like pragmatism must win in this case.

[1]: https://github.com/kisielk/errcheck [2]: https://github.com/gordonklaus/ineffassign [3]: https://pkg.go.dev/builtin#error

https://github.com/kisielk/errcheck

In any case, it’s trivial to detect via static analysis.

https://github.com/kisielk/errcheck

https://golangci-lint.run/usage/linters/ has a solid set of options.

Go has many community linters available, https://github.com/kisielk/errcheck is popular for checking unhandled errors.

If you'd like a combo-pack, check out https://github.com/golangci/golangci-lint which includes all of the popular linters in a configurable way.

I use it in most of my open source projects.

Use https://github.com/kisielk/errcheck for that.

Or prefer https://staticcheck.io/ for a larger set of checks.

_ = index.Index(identifier, your_data)

it will also pass https://github.com/kisielk/errcheck check

eventually we can just panic error

if err := index.Index(identifier, your_data); err != nil { panic(err) }

[1] https://github.com/kisielk/errcheck [2] https://github.com/alecthomas/gometalinter

https://github.com/kisielk/errcheck

I agree that having things like errcheck and go-sumtype all wired up using gometalinter is pretty novel and only partially gross.

This may be considered cheating since it isn't baked into the language but there are tools to do this at build time, here's one: https://github.com/kisielk/errcheck

It is easy to catch on compile time. https://github.com/kisielk/errcheck

If you have

func foo() (string, error)

You can still call it thusly:

foo()

However there are tools to check for unchecked errors like this one: https://github.com/kisielk/errcheck

You mean like errcheck? https://github.com/kisielk/errcheck

I'm not sure if it can find spots where people intentionally throw away an error like in

    val, _ := foo()

    func foo() error { ... }

    foo() // errcheck finds this

[1] https://github.com/kisielk/errcheck

For simply dropping all return values on the ground, there are linters that will complain for you: https://github.com/kisielk/errcheck

(Still would be cool if the Gophers put something like it in the std distro.)

It is something that can be caught with static analysis, however. Someone recently put together an appropriate tool[1] for Go, in fact. It seems to work very well.

[1]https://github.com/kisielk/errcheck