3 ms·

Which you can catch with a linter like https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck. Errors in Go are just values. There's nothing "m

by NateDad 12y ago

Which you can catch with a linter like https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck. Errors in Go are just values. There's nothing "more wrong" about ignoring a return value that is an error or one that is file handle, for example. 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. That's pretty good for basically zero overhead.

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 ago
  Pretty 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 ago
  This 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 ago
    FYI the second use is just assignment, that's why it's not caught by the unused variable rule.
    - ominous_prime 12y ago
      Ah right. It only shadows if it's a new scope.

by NateDad 12y ago

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 ago
Pretty 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 ago
This 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 ago
  FYI the second use is just assignment, that's why it's not caught by the unused variable rule.
  - ominous_prime 12y ago
    Ah right. It only shadows if it's a new scope.