5 ms·

If all functions return a possible error, how do you return a value OR an error?

learc83 6y ago
You can't which is a big part of the problem. You have to trust that the function will only return either and not both. Except in cases where a function does return both. A maybe type would have been a much better solution. I wish people would just accept that go's error handling is a stopgap solution instead of pretending it's a good (or the best) solution. I'd bet a substantial amount that go in 10 years ends up with pattern matching and sum types.
- ribasushi 6y ago
  A "maybe" type is logically incompatible with "subatomic I/O". When a sized-read() syscall results in a short read AND a raised error. The only sensible thing to do is to return both. I am not familiar with Rust, but looking around the docs on Read [https://doc.rust-lang.org/std/io/trait.Read.html#errors https://doc.rust-lang.org/std/io/trait.Read.html#errors] I see: > If an error is returned then it must be guaranteed that no bytes were read. Could someone elaborate how a system can satisfy this guarantee, seems impossible...?
  - UK-Al05 6y ago
    You could write sum type that handles multiple cases. Value Error ValueAndError
  - learc83 6y ago
    That’s hardly a reason not to include a maybe type. In that particular case, instead of a maybe you can use a combination of sum and product types or just an additional ShortRead type. NormalRead | ShortRead | Error This case is also an example of why go’s idiom of using error value or return value doesn’t always work. If you had a maybe type and a general sum type it would be clear when a function was going to return either or both.
  - Measter 6y ago
    That's an API choice. There's no technical reason at all why you couldn't return some kind of error AND read data if you wanted, you'd just have to make your Error type a product type.
- 95th 6y ago
  I like Rust's approach of using `Result` enum
harpratap 6y ago
Can't you simply return a nil error in case you want to return a value? Check for error and if nothing bad happened use the value.
- leshow 6y ago
  There is nothing stopping you from returning both an error and a value. Sure, you can just be diligent everywhere and not do that, we know how well that type of advice usually turns out.
corty 6y ago
You don't, at least not usually. func foo()(value,err) can return any combination of valid or invalid value and error, so (nil, nil) would be possible, or ("valid value", someerror). It is just by convention that you shouldn't do that.
pcl 6y ago
The idiom is to return two values: the desired return value, and also an error value. Go has support for multiple return values, and easy syntax for assigning those positional return values to variables at the call site.

You can't which is a big part of the problem. You have to trust that the function will only return either and not both. Except in cases where a function does return both. A maybe type would have been a much better solution. I wish people would just accept that go's error handling is a stopgap solution instead of pretending it's a good (or the best) solution. I'd bet a substantial amount that go in 10 years ends up with pattern matching and sum types.

ribasushi 6y ago
A "maybe" type is logically incompatible with "subatomic I/O". When a sized-read() syscall results in a short read AND a raised error. The only sensible thing to do is to return both. I am not familiar with Rust, but looking around the docs on Read [https://doc.rust-lang.org/std/io/trait.Read.html#errors https://doc.rust-lang.org/std/io/trait.Read.html#errors] I see: > If an error is returned then it must be guaranteed that no bytes were read. Could someone elaborate how a system can satisfy this guarantee, seems impossible...?
- UK-Al05 6y ago
  You could write sum type that handles multiple cases. Value Error ValueAndError
- learc83 6y ago
  That’s hardly a reason not to include a maybe type. In that particular case, instead of a maybe you can use a combination of sum and product types or just an additional ShortRead type. NormalRead | ShortRead | Error This case is also an example of why go’s idiom of using error value or return value doesn’t always work. If you had a maybe type and a general sum type it would be clear when a function was going to return either or both.
- Measter 6y ago
  That's an API choice. There's no technical reason at all why you couldn't return some kind of error AND read data if you wanted, you'd just have to make your Error type a product type.
95th 6y ago
I like Rust's approach of using `Result` enum

harpratap 6y ago

Can't you simply return a nil error in case you want to return a value? Check for error and if nothing bad happened use the value.

leshow 6y ago
There is nothing stopping you from returning both an error and a value. Sure, you can just be diligent everywhere and not do that, we know how well that type of advice usually turns out.

corty 6y ago

You don't, at least not usually. func foo()(value,err) can return any combination of valid or invalid value and error, so (nil, nil) would be possible, or ("valid value", someerror). It is just by convention that you shouldn't do that.

pcl 6y ago

The idiom is to return two values: the desired return value, and also an error value. Go has support for multiple return values, and easy syntax for assigning those positional return values to variables at the call site.