3 ms·
Do you mean that, each return type should be union'd with potential error types? If there was an error, the value should be meaningless. I don't understand wha
by drekipus 3y ago
Do you mean that, each return type should be union'd with potential error types?
If there was an error, the value should be meaningless. I don't understand what your complaint is against returning both the value and the error.
(Python dev learning Golang, I like the "return error" idea)
- progbits 3y agoIn Go you rely on convention that if err != nil, the other value is meaningless and should not be used. You have to remember to check this, and some interfaces break this convention and use eg. error+some partial value, or nil+nil or other combination. With Rust's Result<T> you either get the value, or the error. Never both or neither. Those states are simply unrepresentable. absl::StatusOr does the same in C++, with slightly worse ergonomics. > If there was an error, the value should be meaningless. I don't understand what your complaint is against returning both the value and the error. Think of it this way: why are you even returning a meaningless value in the first place?
- Smaug123 3y agoMore tersely, returning errors is not the problem. Returning errors and results simultaneously (and relying on context to distinguish them) is the problem. Sums are not well modelled by products.
- kubanczyk 3y ago> If there was an error, the value should be meaningless. I don't understand what your complaint is against returning both the value and the error. What TFA says: yeah, just make invalid states unrepresentable in the type system.
- xigoi 3y agoNo. If there was an error, there should be no value at all.