3 ms·

For a Result<T, E> the returned type will either be an Ok(T) or an Err(E). Not both, so it's not a composite type like golang with defining a Tuple of (T, error

For a Result<T, E> the returned type will either be an Ok(T) or an Err(E). Not both, so it's not a composite type like golang with defining a Tuple of (T, error). So you can then do a match statement like this: match maybe_error() { Ok(t) => {}, // we succeeded Err(e) => {}, // we did not succeed } Result itself is an enum with Ok and Err variants. [0] Some functions use Option<T> which will either be Some(T) or None. [0]: https://doc.rust-lang.org/std/result/index.html https://doc.rust-lang.org/std/result/index.html

flohofwoe 6y ago
Ok, this requires Rust's "rich enum type" (whatever that's called), and some sort of generics, both of which Go doesn't have. But you can create the "gist" of this sort of return-based error handling even in C, by returning a struct which contains both an error code and a value-payload, it's just not as convenient (because C lacks generics), or as "safe" (because one can access the value even when an error is returned), but it still would be better than "old-school" C code which splits the error-code and success-value into a simple return value and an out-pointer, and arguably also better than C++ exceptions.
- throwaway8941 6y ago
  >"rich enum type" (whatever that's called) Algebraic data types, or sum types, or discriminated unions. GP also forgot to mention that Rust (among other languages with support for ADTs) force you to handle all possible values, so you simply can't forget to handle an error.
  - steveklabnik 6y ago
    (They're called 'enums' in Rust though, your parent is correct.)
  - thatswrong0 6y ago
    > so you simply can't forget to handle an error. This is such an important point, and I know people may think its outrageous that this could happen, but I work with a bunch of talented programmers, and still we've had the occasional bug crop up in our Golang codebase where we have a `val, err = doSomething()` without an ensuing `if err != nil { }` check which was missed by the programmer and by the reviewer. Or even better, we've had `val, _ = doSomething()` occur, the result of debugging to get around the unused variable compilation error. It's 2020. Just like nil-pointers, this is an issue that is for the most part _solved_ and shouldn't exist in modern languages. Our programming languages should be constructed with the fact that we're fallible humans in mind.
- nicoburns 6y ago
  > Ok, this requires Rust's "rich enum type" (whatever that's called), and some sort of generics, both of which Go doesn't have. This is one of the reasons so many people are calling for Go to get generics. > or as "safe" (because one can access the value even when an error is returned) Which is one of the key things one wants from an error handling mechanism: the inability to misuse it.
  - apta 6y ago
    > This is one of the reasons so many people are calling for Go to get generics. Even if it gets them at some point, the language still needs support for algebraic types, which not surprisingly, the golang authors "don't see it as useful".

flohofwoe 6y ago

Ok, this requires Rust's "rich enum type" (whatever that's called), and some sort of generics, both of which Go doesn't have. But you can create the "gist" of this sort of return-based error handling even in C, by returning a struct which contains both an error code and a value-payload, it's just not as convenient (because C lacks generics), or as "safe" (because one can access the value even when an error is returned), but it still would be better than "old-school" C code which splits the error-code and success-value into a simple return value and an out-pointer, and arguably also better than C++ exceptions.

throwaway8941 6y ago
>"rich enum type" (whatever that's called) Algebraic data types, or sum types, or discriminated unions. GP also forgot to mention that Rust (among other languages with support for ADTs) force you to handle all possible values, so you simply can't forget to handle an error.
- steveklabnik 6y ago
  (They're called 'enums' in Rust though, your parent is correct.)
- thatswrong0 6y ago
  > so you simply can't forget to handle an error. This is such an important point, and I know people may think its outrageous that this could happen, but I work with a bunch of talented programmers, and still we've had the occasional bug crop up in our Golang codebase where we have a `val, err = doSomething()` without an ensuing `if err != nil { }` check which was missed by the programmer and by the reviewer. Or even better, we've had `val, _ = doSomething()` occur, the result of debugging to get around the unused variable compilation error. It's 2020. Just like nil-pointers, this is an issue that is for the most part _solved_ and shouldn't exist in modern languages. Our programming languages should be constructed with the fact that we're fallible humans in mind.
nicoburns 6y ago
> Ok, this requires Rust's "rich enum type" (whatever that's called), and some sort of generics, both of which Go doesn't have. This is one of the reasons so many people are calling for Go to get generics. > or as "safe" (because one can access the value even when an error is returned) Which is one of the key things one wants from an error handling mechanism: the inability to misuse it.
- apta 6y ago
  > This is one of the reasons so many people are calling for Go to get generics. Even if it gets them at some point, the language still needs support for algebraic types, which not surprisingly, the golang authors "don't see it as useful".