3 ms·
> 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 th
by 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.