4 ms·
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
by corytheboyd 2y 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?
- deergomoo 2y agoIn 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.
- corytheboyd 2y 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.