On: Cold Showers: For when people get too hyped up abo...

[networkimprov]

You certainly can throw errors away in Go -- in various ways. It's one of the notable flaws in a largely cohesive, sensible language. (Which I use daily.)

    success, err := fail()
    do(success)

    success, _ := fail()

    fail()

[david-cako → networkimprov]

I suppose my point, more specifically, is that functions return errors instead of opaquely throwing them. Most languages expect you to know where they're going to occur and catch them as close to their occurrence as possible, in Go you are explicitly carrying them along the whole way. Some people don't like this, I prefer it.

True, if you completely ignore the function's return values, you can throw errors away, but then you wouldn't be using the language in the way that makes it powerful to me; that there are simple and clear interfaces that you interact with.

[jchw → networkimprov]

The second one is pretty intentional - it'd be annoying it were downright impossible.

The first and third one fails on go vet. The first one also fails to compile if you never read from err in the entire function.

[networkimprov → jchw]

Vet accepts the third, and may (I forget) accept the first if err is redeclared or simply assigned.

[jchw → networkimprov]

My bad, I was thinking of errcheck, which is more thorough and integrated into most Go linting tools like Go CI linter.

https://github.com/kisielk/errcheck

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