10 ms·
> And in cases where a function returns an error and a value (where the error generally indicates the validity of the value), you'll get a compile error if you
by frou_dh 12y ago
> And in cases where a function returns an error and a value (where the error generally indicates the validity of the value), you'll get a compile error if you don't check the error.
This compiles:
package main
import "errors"
func main() {
x, err := f()
if err != nil {
return
}
y, err := g()
h(x, y)
}
func f() (x int, err error) { return 1000, nil }
func g() (y int, err error) { err = errors.New("boo"); return }
func h(x, y int) { println(x/y) }
(I do write Go most days and rather like it, but apologists for its weak parts are legion)
- NateDad 12y agoPretty sure errcheck will catch that too. The thing that bugs me is the people that make up problems that are not at all problems in real day to day coding.
- ominous_prime 12y agoThis looks more like a bug. The second err is a valid redeclaration, and so should be checked for usage on it's own. Though the redeclaration through multiple assignment is itself a bit of a wart that the programmer hast to be wary of, so it may not be a big deal. In any case, the go compiler is very helpful in most cases, and better tooling can improve things further.
- NateDad 12y agoFYI the second use is just assignment, that's why it's not caught by the unused variable rule.
- ominous_prime 12y agoAh right. It only shadows if it's a new scope.