Yeah, 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...
Eh. 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.
>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.
Re:The Zen of Go
by earthboundkid on Monday February 24, 2020 @10:49AM
(#22405030)
Your example doesn't compile: 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.
Don’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.
Re:The Zen of Go
by throwaway894345 on Tuesday February 25, 2020 @07:26PM
(#22419079)
I do wish Go would adopt sum types, but in practice errors like you describe are vanishingly rare. It’s mostly a theoretical problem.
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.