3 ms·

> Both force you to handle the error That is definitely not true of the second, especially when the language is incorrectly or insufficiently pedantic like Go.

> Both force you to handle the error That is definitely not true of the second, especially when the language is incorrectly or insufficiently pedantic like Go. Notably, because the base pattern is foo, err := Bar() it is very easy to write something like: foo, err := Bar() // code, no error check bar, err := Baz() // code, no error check qux, err := Qux() if err != nil { ... } And Go is perfectly happy with that, because while it will complain about unused variables it doesn't say anything about dead stores. You need external tools to warn about this issue, as well as ignoring the returns entirely. And then of course because this pattern requires having a valid "result" value which ends up in scope, it's very easy for bugs to creep in where this result value does get used even in case of error.

nordsieck 4y ago
IMO, that would look suspect to me. It's much more common to see if foo, err := Bar(); err != nil { It's a pretty immediate yellow flag for me if you're not doing that. In general, I've found that not catching errors is not a practical problem when writing go. Whereas things like interface nil ambiguity and the way defer and closures interact bit me a few times.
- mdaniel 4y ago
  That's all fun and games if you want `foo` to be used in some `else` block but it just straightup wrong for using `foo` further down in the method as it scopes the decl (`:=`) to the `if` package main import ( "fmt" ) func Bar() (string, error) { return "hello", nil } func main() { if foo, err := Bar(); err != nil { panic(err) } fmt.Printf("foo is %q", foo) } $ go run foo.go ./foo.go:12:8: foo declared and not used ./foo.go:15:30: undefined: foo > In general, I've found that not catching errors is not a practical problem when writing go Yeah, good for you, but I am obviously not a consumer of your code because I have lost track of the number of times I have to use software written by folks that try to be heroes and program using dumb editors that cheerfully don't warn about swallowing err

nordsieck 4y ago

IMO, that would look suspect to me. It's much more common to see if foo, err := Bar(); err != nil { It's a pretty immediate yellow flag for me if you're not doing that. In general, I've found that not catching errors is not a practical problem when writing go. Whereas things like interface nil ambiguity and the way defer and closures interact bit me a few times.

mdaniel 4y ago
That's all fun and games if you want `foo` to be used in some `else` block but it just straightup wrong for using `foo` further down in the method as it scopes the decl (`:=`) to the `if` package main import ( "fmt" ) func Bar() (string, error) { return "hello", nil } func main() { if foo, err := Bar(); err != nil { panic(err) } fmt.Printf("foo is %q", foo) } $ go run foo.go ./foo.go:12:8: foo declared and not used ./foo.go:15:30: undefined: foo > In general, I've found that not catching errors is not a practical problem when writing go Yeah, good for you, but I am obviously not a consumer of your code because I have lost track of the number of times I have to use software written by folks that try to be heroes and program using dumb editors that cheerfully don't warn about swallowing err