3 ms·
> ... error verifications in Go ... you understand by reading your code the places where error can occur or where you decided to ignore errors (By using _) Thi
by frou_dh 12y ago
> ... error verifications in Go ... you understand by reading your code the places where error can occur or where you decided to ignore errors (By using _)
This compiles:
package main
import "errors"
func main() {
f()
println("hello erroneous world")
}
func f() error { return errors.New("boo") }
- cjslep 12y agoSure, you can fail to capture any return variable (not just errors) in lots of languages. What is available to Go that isn't in, say, C++ or Java is the "black-hole variable" marked with the underscore _ so its very much a stylistic choice to insert it in Go where errors would be returned. Applied consistently, you can gain a lot of readability. But it is very much a stylistic choice.
- NateDad 12y agoWhich 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 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.