Re:Gopher Wrangling. Effective error handling in Go
by janosdebugs on Tuesday June 20, 2023 @06:20AM
(#36401964)
Go is a weird mix. It doesn't even let you create an unused variables, but happily lets you ignore errors or return variables. That makes no sense and is on Go, not on the admittedly quite excellent tooling provided by people who are not the Go dev team (third party). An IDE is just as much third party to the language as golangci-lint is.
[ Parent
| on HN ]
Re:Gopher Wrangling. Effective error handling in Go
by aatd86 on Tuesday June 20, 2023 @06:49AM
(#36402168)
Ignoring an error is a red herring.
You have to go out of your way to actually use a special character to do it.
No, one real issue that can happen if one is not careful (but fortunately linters help) is variable shadowing which may lead to some errors being unchecked.
In general, I find that error handling is not as horrible as some seem to purport.
Re:Gopher Wrangling. Effective error handling in Go
by janosdebugs on Tuesday June 20, 2023 @07:10AM
(#36402353)
> You have to go out of your way to actually use a special character to do it.
Only if the function returns more than the error. You can happily do this without errors:
fh = os.Create("/some/file")
defer fh.Close()
Needless to say, this is a terrible idea if the underlying filesystem can give you an error at close time, e.g. on NFS. The correct way to write the above code would be: fh = os.Create("/some/file")
defer func() {
if err := fh.Close(); err != nil {
// Do something with the error
}
}()
Yet, I see a lot of the former and very few instances of the latter.
Re:Gopher Wrangling. Effective error handling in Go
by aatd86 on Tuesday June 20, 2023 @08:28AM
(#36403065)
Oh you're right. I had forgotten about that.
I think it's mostly an API legacy mistake. Close should probably return (bool, error).
Probably a remnant of coding in C wrt sentinel values.
Re:Gopher Wrangling. Effective error handling in Go
by janosdebugs on Tuesday June 20, 2023 @08:56AM
(#36403319)
You could still ignore both returned values. Go shouldn't allow ignoring returns without explicit dogsleds (underscore) at all if it were to stay "in character".