Given the unwieldlyness of exceptions, perhaps what I would really want in an OOP language is a construct to say "return from this function, AND the calling function, and return value X from the calling function.".
Conversation
Replying to
This gets tricky when you consider different return types. This either requires that functions don't declare a return type, or that all of them return some kind of "result" type.
1
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.
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
Show replies