You almost always defined your variables. None of this `foo, err := getFoo()` nonsense.
Most functions return an error so err is already defined:
func doIt(a, b) (result string, err error) { ... }
func doIt(a, b int) (result string, err error) {
var x, y string
x, err = doA(a)
if err != nil {
return
}
y, err = doB(b)
if err != nil {
return
}
result = x + y
return
} var foo *Foo
if foo, err := getFoo(); err == nil {
return nil, err
}
// foo is usable now
Re:Why I love Go
by lobster_johnson on Tuesday December 05, 2017 @11:44PM
(#15858589)
I suspect you don't know how := works.
./test.go:14:15: foo declared and not used
Re:Why I love Go
by flip_rect_red on Wednesday December 06, 2017 @02:56AM
(#15859356)
it appeared to be a typo, and as you suggest the compiler caught it
var foo *Foo
var err error
if foo, err = getFoo(); err != nil {
return nil, err
}
//foo is usable now
Re:Why I love Go
by lobster_johnson on Wednesday December 06, 2017 @03:22AM
(#15859500)
That solves nothing. The point was that you pollute the scope with error variables, leading to dangerous logic errors that can be hard to spot. Your snippet is no better than:
foo, err := getFoo()
if err != nil {
return nil, err
}
Re:Why I love Go
by xenoncross on Tuesday December 05, 2017 @10:33PM
(#15858248)
There are real problems, and not real problems. I'd classify this as a not real problem. How hard is it to name errors differently when it would be a real problem? A few keystrokes.. and BOOM! Problem solved.
I wonder what is the correlation between volume of complaining about minutia such as this compared to real life ability and level of accomplishment.
Re:Why I love Go
by lobster_johnson on Tuesday December 05, 2017 @11:11PM
(#15858410)
When you work with Go every day (which I've done for last two years or so), small problems become significant annoyances.
It's a decent language, but it's also a deeply flawed one. I could mention many other, bigger flaws, but this particular discussion was about errors.
Also, it's actually okay to debate minutia. Dismissing something as "not real problems" is, well, dismissive.
For example, consider:
Now your scope has an "err" and you open yourself to logic errors such as: Spot the (heh) error? It's caused by ":=" allowing variables to be reassigned.You can avoid this dangerous pollution, but it's super ugly:
(You have to have the return in the second branch, otherwise "go vet" will complain. Sigh.)I have lots of these, and they're not helped by the fact that Go has no type-level mechanism to guard against the misuse of multiple-return values. That is, in the above, either "foo" or "err" are usually set, and if "err" is set, it means "foo" isn't. But the type system doesn't prevent you from accidentally ignoring "err" and using "foo", or vice versus. This gets even worse if the func returns a (non-pointer) struct as its value.
The fact that Go allows shadowing (exacerbated by the convention of using "err" as every single error variable) and promotes the reuse of variables (e.g. the above ":=", or declaring "err" outside a loop) also means it's super easy to assign the wrong thing.
All of the above are my single biggest source of bugs during development. That, and how accidentally using nil/zero values, including the damnable nil map/slice cases.
"go vet" (whose shadowing check is disabled by default (!)) and the various linters only go some ways towards helping here. The errcheck linter (which you can enable through gometalinter) is absolutely essential.