4 ms·
The only thing bad about Go's version (other than the usual repetitive code complaints) is it's easy to ignore (ie forget) to handle an error. And really much
by cpuguy83 10y ago
The only thing bad about Go's version (other than the usual repetitive code complaints) is it's easy to ignore (ie forget) to handle an error.
And really much of the error handling in Go is by convention (ie, `if err != nil { return nil, err }`) rather than actual language semantics.
Honestly it would be nice to be able to always return the error (without special macros or symbols) if there is one unless I've explicitly setup a handler block.
- brandur 10y agoI've also found (the hard way) that it's possible to mistype a conditional as `err == nil` when it should be `err != nil`. It's a really dumb mistake, but will waste time as you track it down (without the compiler's help).
- stouset 10y agoNot to mention forgetting to `return` nil, err. If you just type `nil, err`, you don't handle the error and nothing complains. Oops.
- iand 10y agoEr... https://play.golang.org/p/QyQVFfPIhx https://play.golang.org/p/QyQVFfPIhx
- stouset 10y agoIs this a recent change? I've with 100% been bitten by this before, repeatedly, and the go compiler did nothing to warn about it.
- masklinn 10y agoMaybe for a side-effecting function which would only return an error? edit: nope, fails with "err evaluated but not used".
- stouset 10y agoI'm genuinely stumped. If they've fixed this, that's fantastic because I have absolutely shipped code with this bug to a production environment.
- iand 10y agoI've been working with Go for 4 years and I've not encountered it. Perhaps there was an edge case where it was allowed, but I don't recall it.