[sapiogram]

errcheck will not catch everything. For example, it will not stop you from using a value before checking the error, as long as you check the error later. I've personally broken things in production because of that corner case, despite (usually) being very careful about error handling.

[Cthulhu_]

No language or linter will be perfect, and IMO unit tests should be written for what the compiler doesn't do for you. In this case, your unit tests missed code paths, which should show up in a code coverage analysis or fuzz test.

[treyd]

Rich type systems like Rust's do completely prevent this type of mistake. You don't need unit tests to ensure that the error condition is handled somehow because we statically assert it within the type system of the language.

[9rx]

Handling an error is pointless if you don't handle it correctly, and for that you need unit tests anyway, so you still need to write the tests and once you've done that it is impossible to encounter the mistake without knowing it no matter how you slice it.

But your editor can give some more realtime feedback instead of waiting for your tests to run, so I guess that's cool.

[the_gipsy]

You need to give it a try

[9rx]

Give improperly handling an error a try? I’m good. I prefer my software to function correctly.

[sapiogram]

In Rust it's literally impossible to use a returned value without checking the error. This bug also cannot happen with Java, C# or Javascript exceptions. This particular failure mode is unique to Go.

[simonask]

It's not unique - C has it, and error-code-flavored C++ can emulate it too. ;-)