6 ms·
There’s other reasons too! I’ve written the following: if v, err = func(); err != nil { nil, err } … and then went on to use `v`. Thanks to `v
by stouset 7y ago
There’s other reasons too! I’ve written the following:
if v, err = func(); err != nil {
nil, err
}
… and then went on to use `v`. Thanks to `v`s zero value being legitimate (and not nil like a pointer would be), the program continues on as if everything is okay. In case you didn’t catch it, I forgot the `return`.
Rust takes a much better approach with Result, where the return value is either `Ok(v)` or `Err(e)`, and there’s no way to access a meaningless value for the other possibility.
- coldtea 7y agoYeah, and this is so simple a change (compiler wise) and far more stronger a guarantee I don't see why Go didn't implement it... At least then errors as return values would be solid. Of course now they make programmers do all the extra error wrapping thing in 1.14 to pass "richer" errors...
- pm90 7y agoEh. It’s verbose but I like it. It makes me think about the code a bit when I have to write a descriptive error wrap. Kind of annoying I guess... I haven’t written ultra large go codebases though so ymmv.
- coldtea 7y ago>It’s verbose but I like it. It makes me think about the code a bit when I have to write a descriptive error wrap. Having the compiler force you, as is my suggestion, would make you think even more -- or not be able not to think and skip the error check or miss it.
- deleted 7y ago[deleted]
- earthboundkid 7y agoYour example doesn't compile: https://play.golang.org/p/KQwXqTZHSPF https://play.golang.org/p/KQwXqTZHSPF Go doesn't allow values to just be referenced without having some use, e.g., JavaScript's `"use strict";` hack could not be done. In general, I have never seen a bug caused by accidentally ignoring an error. It's a theoretical concern, but not a real world problem.
- stouset 7y agoDon’t know what to tell you, I have personally made this mistake and not had this caught by the compiler. I haven’t used go in several years at this point, so it’s entirely possible this is a newly-caught scenario by the compiler. Regardless, the fundamental point stands. Using tuples to return “meaningless” values alongside errors allows developers to mistakenly use those meaningless values.
- throwaway894345 7y agoI do wish Go would adopt sum types, but in practice errors like you describe are vanishingly rare. It’s mostly a theoretical problem.