3 ms·
Regular go style is to return (value, error) tuples from most functions which can have runtime errors. This raises a bunch of questions which, thanks to some o
by gorgoiler 3y ago
Regular go style is to return (value, error) tuples from most functions which can have runtime errors. This raises a bunch of questions which, thanks to some of the comments in this thread, I hadn’t really thought about until now.
I think it is implied that one should not return both a value and an error. Is this true? Is there much code in go that returns both and lets you decide if you want to take the value and carry on, or take the error and stop?
Is there much idiomatic code where a function returns a tuple of actual values? For example a function in some shipping code that returns the largest dimension of a package to be shipped where it can only be of a maximum size or a maximum weight? Does this kind of idiomatic code also rely on the contract that only one value will be set?
Does go have the typing facility to have a union type for both a value and an error, and does anyone use this in preference of returning tuples? If types in go can be null then this still allows for ambiguity and it would surely be unpopular to produce code that breaks the value/error tuple pattern, but I assume some left field hackers are breaking the rules somewhere.
- aldanor 3y agoThat's called 'sum types' and that's what Go lacks. See some bikeshedding and ongoing discussion [here](https://github.com/golang/go/issues/57644 https://github.com/golang/go/issues/57644).