5 ms·

Interesting. I couldn't disagree more! Combinators are very handy for error handling in Rust. More than that, combinators (and their limits) are essential to un

Interesting. I couldn't disagree more! Combinators are very handy for error handling in Rust. More than that, combinators (and their limits) are essential to understand in order to motivate `try!`. Indeed, in Rust, matching against a Result type explicitly isn't especially common. Instead, one uses `try!`. `try!` abstracts three things at once: case analysis, error conversion and control flow. The chapter actually goes into detail and demonstrates why combinators and match expressions are insufficient for ergonomic error handling. IMO, this approach leads to the greatest understanding, because everything is laid bare and follows a nice progression from first principles. With that said, in a book, I totally agree that the chapter could be broken up into more manageable pieces. But I do think all of the content there is essential for understanding how to do error handling in Rust. I feel pretty safe in saying that I use all of those concepts in most crates I've published. Thank you for replying by the way. I'll continue to noodle on your thoughts and see if there's a happy place between us. (I kind of suspect that happy place is the new book, with content delivered in more manageable chunks. Alas, my blog is not book. :P)

Animats 10y ago
"try!" has a built-in, hidden function return. It's only useful if the appropriate error action is to immediately bail out of the function. It implies that your program should be structured as functions which either succeed or fail, and that you don't need to log or display errors where they occur.
- burntsushi 10y ago
  > "try!" has a built-in, hidden function return. Hence the reason I said that it abstracts control flow. > It's only useful if the appropriate error action is to immediately bail out of the function. Which is exceptionally common. > It implies that your program should be structured as functions which either succeed or fail, and that you don't need to log or display errors where they occur. None of this is true, and I do log errors when they occur in Rust programs. (See ripgrep.) `try!` is a convenience. Since errors are plain old values like anything else, you don't actually need to use it if it doesn't fit.

Animats 10y ago

"try!" has a built-in, hidden function return. It's only useful if the appropriate error action is to immediately bail out of the function. It implies that your program should be structured as functions which either succeed or fail, and that you don't need to log or display errors where they occur.

burntsushi 10y ago
> "try!" has a built-in, hidden function return. Hence the reason I said that it abstracts control flow. > It's only useful if the appropriate error action is to immediately bail out of the function. Which is exceptionally common. > It implies that your program should be structured as functions which either succeed or fail, and that you don't need to log or display errors where they occur. None of this is true, and I do log errors when they occur in Rust programs. (See ripgrep.) `try!` is a convenience. Since errors are plain old values like anything else, you don't actually need to use it if it doesn't fit.