4 ms·
If you care, you can't realistically forget. There are linters that will find your missed error checks.
by NateDad 8y ago
If you care, you can't realistically forget. There are linters that will find your missed error checks.
- hu3 8y agoIn Go, if a function returns an error you have to explicitly handle or suppress it. Otherwise code just doesn't compile. There's no margin to "forget".
- insertnickname 8y agoThat's not quite true. For instance, the error value returned from `fmt.Printf`[0] is usually ignored silently. [0] https://godoc.org/fmt#Printf https://godoc.org/fmt#Printf
- jerf 8y agoIt's true that functions that return (result, error) tuples are hard to miss the errors from, because you have to explicitly either at least accept it, or ignore it. It's both visually obvious that you've dropped the error and there are linters to catch this for you (which I highly recommend integrating into pre-commit hooks). However, if a function just returns an error, but no result value, it is indeed easy to silently drop that error without realizing it by simply invoking the function and not catching the result at all. To which, again, I'd highly recommend using linters at commit time or even code save time.
- jcelerier 8y ago> In Go, if a function returns an error you have to explicitly handle or suppress it. Otherwise code just doesn't compile. ah, yeah, great idea. in practice this just means that most Go projects are minefields of if err != nil { panic(err) } or if err != nil { return err } ie a manual & repetitive implementation of assert for the first case and manual & repetitive implementation of an exception call stack for the second. thank you very much, I'll take the automated version known as exceptions instead.
- weberc2 8y agoYes, Go requires explicit error propagation, but this is desirable because 1) errors are no different than other values so they don’t get special flow control and 2) people are much more likely to properly handle errors if they have to think about handling in every call frame (I.e., error handling bugs are much rarer in Go than Python or JS or etc).
- _ZeD_ 8y ago>>> (I.e., error handling bugs are much rarer in Go than Python or JS or etc). [citation needed]
- weberc2 8y agoI've been writing Python extensively for 10 years and Go for 6. Recently, I've been the exceptions cop in our Python/JS shop, and every week I see errors in prod that would almost certainly not exist in Go code (both because Go is statically typed but also because Go developers check their errors). Take this anecdote for whatever it's worth to you.
- weberc2 8y agoThis isn’t true. This is a valid program, after all—even though fmt.Println returns (int, error): func main() { fmt.Println(“Hello”) }
- masklinn 8y ago> In Go, if a function returns an error you have to explicitly handle or suppress it. If a function only returns an error, or if it returns both a value and an error and you care for neither, you can absolutely ignore them entirely. And when you can "suppress" an error and still access the value, it's not really impressive.
- silasdavis 8y agofile, _ := ioutil.ReadFile(filename)
- whateveracct 8y agoThis is classic Go design, for better or worse. "Just use this ad-hoc, unprincipled tool to counter a shortcoming of the core language."