3 ms·
>The way in Go to handle possibly-failing functions is to have multiple return values: an actual result, and an error. If the error is nil, then the actual resu
by eznzt 6y ago
>The way in Go to handle possibly-failing functions is to have multiple return values: an actual result, and an error. If the error is nil, then the actual result is sensible; otherwise the actual result is meaningless. This means you can forget to check the error and use a bogus result and, because there are no compiler warnings (another wtf), you will know nothing of this until things fail at runtime.
? You can't forget to check the error because not checking err is a compiler error unless you forcibly mute it by using _
- Cthulhu_ 6y agoWhile you're correct, you can still avoid handling an error and not get any feedback from the compiler or linters by doing something like: val, err := something() val2, err := somethingElse() if err != nil // etc You can - and all the examples usually do - reuse and shadow an 'err' variable, and tooling won't complain as long as something is done with it at least once. If Go wants to enforce not ignoring errors, it still has a few holes like this to fix.
- eznzt 6y agoI see now. That is indeed one of the things I hated about Go, having to reuse err (or maybe, making the mistake of reusing err) several times in a single function.