Hacker News new | ask | show | jobs
by corytheboyd 645 days ago
Is… NOT ignoring errors just not an option? I don’t get it. If you propagate errors up but not all the way to being handled, haven’t you failed in a very simple, easy to fix way? Should you have a linter catching these things?
1 comments
deergomoo 645 days ago
In this case the issue is that defer is a very good way to ensure you don’t forget to close the file in any branches, but a bad way to return values (you have to set the value of a named return variable, which is one of Go’s odder features).

> Should you have a linter catching these things?

JetBrains’ GoLand will in fact warn you of this. If the error truly is immaterial you can instead do

defer func() { _ = f.Close() }()

which is verbose but explicit in its intent to ignore the error.

link
corytheboyd 645 days ago
> […] you have to set the value of a named return variable

Ahhhh okay I see it now. I definitely prefer to not use that feature as well, and I’m surprised it’s even there given how well the rest of the language adheres to “only one way to do things”. Doubly agree that it’s a strange “hack” for forwarding the deferred return value… oof

> JetBrains’ GoLand will in fact warn you of this

Heh yeah that’s what prompted me to ask, as I noticed (and very much appreciated) these hints. 100% agree with the verbose-but-explicit example you gave, and do that myself.

link