How does Rust solve this for different types of errors?
Conversation
You define a sum type with the possible errors and implement the From trait for implicitly converting from each. For example, #[derive(From)] enum MultipleError { One(ErrorOne), Two(ErrorTwo) }. You can use the ? operator (or the legacy try!) to return one of the variant types.
1
By the way, I only linked the old 1.9 try! page because it's what came up at the top of the Google results. There are examples with the new built-in ? syntax rather than the legacy try! macro doing the same thing in the current page which I meant to link: doc.rust-lang.org/std/macro.try..
2
1
Not trolling: once you've added this amount of syntax sugar, how is the Rust approach much different from checked exceptions?
1
2
It doesn't involve invisible control flow through functions or unwinding. You can see every potential return directly in the source code. The syntactic sugar is very light was implemented as a macro, which can be user-defined too. The operator is just a short hand form of it.
1
The Result enum is also a completely normal data type, as are enums of multiple possible errors. Sum types aren't something that exists for this specific use case. It's a general purpose language feature and Result can be used just like any other normal data type.
1
Using this sugar for propagating the error upwards is only one small part of using it. It's very misleading to portray it as the same thing as checked exceptions just because one small aspect of it is superficially similar (and yet much different since control flow is explicit).
1
Sum types are one of the core data types just like tuples (product types). They're very broadly applicable and widely used, far beyond error handling. It's simply natural to use a type resembling Either<A, B> for error reporting and Rust just has a standard type and idiom for it.
1
The syntactic sugar is something that arose naturally and was originally user-defined outside the standard library. It's a trivial macro encoding a common pattern in code: propagating errors upwards. It's so widely used that it was given an operator. Doesn't make it an exception.
1
You're misunderstanding if you think there's any significant language complexity or syntactic sugar dedicated to error handling. The Result type isn't a language feature. It's defined as `enum Result<T, E> { Ok(T), Err(E) }` which is a sum type used via pattern matching (match).
1
In many cases, Option<T> is used instead because a value is either present or not present with no meaningful information to convey via an error. Propagating that upwards is also common, so people defined a try_opt! macro for that too, which was replaced with the ? operator too.
And that's just `enum Option<T> { Some(T), None }`. You can define equivalents to these types and the try! / try_opt! macros yourself. Those aren't language features. The only language feature is an ? operator simply avoiding the noise of macro invocation for something so common.