Hacker News Reader

Comment by Hendrikto | Hacker News Reader

You can ignore errors in Rust too, just like any language. And people do, just like with any language.

In Rust you have to explicitly state that you're ignoring the error. There is no way to get the value of an Ok result without doing something to handle the error case, even if that just means panicking, you still have to do that explicitly.

In Go you can just ignore it and move on with the zeroed result value. Even the error the compiler gives with unused variables doesn't help since it's likely you've already used the err variable elsewhere in the function.

True, but running errcheck will catch cases where you accidentally ignore the error. Maybe not as good as having it built-in to the language like Rust, but the goal of error check safety is achieved either way.

And there's a few cases like Print() where errors are so commonly ignored you don't even want to use the "_" ignore syntax. Go gives you the poetic license to avoid spamming underscores everywhere. error linters can be configured to handle a variety of strictness. For non-critical software, it's OK to YOLO your Print(). For human-death-on-failure software you may enforce 100% handling, not even allowing explicit ignore "_" (ie become even stricter than Rust language default)

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.

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.

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.

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.

You need to give it a try

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

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.

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

I would think it's the job of the static analyzer to ignore errors for print. Unfortunately, the proper and consistent use of an appropriate static analyzer is not common in typical rushed corporate settings. Rust avoids this dilemma by enforcing it at the compiler level. There are numerous other types safety reasons too why Rust is safer for careless teams.

I really wouldn't object if some of the rules in the Go world currently living in the broad linter space were to be moved to the compiler. To a point Go's ecosystem has some reasonable defaults but it could be a bit stricter I think.

That's only the case if you consume the return value. It's perfectly legal (though it gives you a compiler warning) to call a function that returns a Result and never check what actually happened.

Reply on news.ycombinator.com