Hacker News Reader

> With Go making errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error.

Right, but because `err` ends up getting re-used in so many cases, you can re-assign it and forget to do anything about it (which is what I've found in most cases where an error was inappropriately suppressed in Go).

In most cases, simply bubbling up the error to something that will generically handle all errors is the right thing to do, and in the case of exceptions, even if you don't know about one, that is what will happen. I just sampled a handful of the top Golang repos on Github, and found very few cases of anything more than the standard `if err != nil; return nil, err' pattern that just bubbles the error up.

Last time I wrote go you could write `doThingAndMaybeReturnErr()` without the `_ =`. Has this changed?

The alternative is Zig or Rust's thing, where you still have explicit error handling but you don't repeat the same four lines all the time. This is maybe helpful because in Go one has to read those lines carefully to see if anything unexpected is happening.

Linters such as golangci[1] which will warn if you ignore the return value. If you ever write Go again I highly recommend you look at golangci -- the security checks have been really helpful to me.

[1] https://golangci-lint.run/

> Since Go makes errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error.

LoadData(&data)

Does this function return nothing or an error ?

It returns nothing or the compiler/linter/ide will tell you.

Which compiler/linter/IDE is that? The Go compiler and linter certainly don't tell you:

https://play.golang.org/p/k-eTs3dC_wK

Note that Go playground also runs go vet, a static analysis tool.

You're probably right. I use Goland and I just think of it as a natural extension to Go. I shouldn't.

> Since Go makes errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error.

This is a bad thing because it’s not narrow. It’s like a language’s “catch” statement not allowing you to catch specific exceptions. Once someone has decided to throw away an error with the underscore assignment, all future errors the underlying might return are swallowed as well.

In other words, it takes even more boilerplate to have narrower error exemptions than to have the generic exemption.

> It seems to me that the result is more errors are properly handled in Go - because they are explicit - while uncaught exceptions often cause bugs that make it to production.

An error in go that is blindly returned all of the way up the stack has no difference with an uncaught exception.