5 ms·
The "Go authors" (by that I assume you mean the Go team) have very explicitly stated that they view the current way Go does error handling as a major problem[1]
by unscaled 5y ago
The "Go authors" (by that I assume you mean the Go team) have very explicitly stated that they view the current way Go does error handling as a major problem[1][2].
[1] https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
[2] https://github.com/golang/go/issues/32437#issuecomment-512035919 https://github.com/golang/go/issues/32437#issuecomment-51203...
- akira2501 5y agoI was referring to what is written in "Effective Go" which seems to contradict [1] on style. Effective Go, on if: https://golang.org/doc/effective_go#if https://golang.org/doc/effective_go#if
- unscaled 5y agoThe section that you're linking to in Effective Go does not state anywhere that "branches are clunky, they are so intentionally to make the points where your code branches much more obvious". It only promotes the concept that of using guard-clause style ifs that return an error and have no else clause, gradually eliminating each possible error condition. This style of programming was later termed in the Go community "Aligning the happy path to the left"[1][2] [1] https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88 https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea... [2] https://maelvls.dev/go-happy-line-of-sight/ https://maelvls.dev/go-happy-line-of-sight/ I wholeheartedly agree that this style makes code more readable and I have adopted it - and encouraged others to adopt it - in other languages besides Go. This style would stil be followed with the try or check/handle proposals. For instance, let's take the example: f, err := os.Open(name) if err != nil { return err } d, err := f.Stat() if err != nil { f.Close() return err } codeUsing(f, d) f.Close() return nil With the simple try proposal that would be: f := try(os.Open(name)) defer f.Close() d := try(f.Stat()) codeUsing(f, d) With OP's variant of the try proposal, using a question mark this is arguably even more readable (less noisy): f := os.Open(name)? defer f.Close() d := f.Stat()? codeUsing(f, d) As you can see, these proposal reduce - not increase - nesting, so they are completely in line with what Effective Go is saying.
- sagichmal 5y agoYou continue to assert that error handling adds noise to a block of code. This is an opinion, that's fine, but it's not an objective truth. In many many domains -- in fact the domains which Go targets -- error handling is equally important to business logic.
- sagichmal 5y agoThat is not at all what those links indicate.