4 ms·
First, thanks for taking time to write essential blog posts/documentation. Here would be my suggestions, I hope they are useful: 1. Its about error handling.
by papaf 10y ago
First, thanks for taking time to write essential blog posts/documentation.
Here would be my suggestions, I hope they are useful:
1. Its about error handling. Options are conceptually similar but they're not error handling. Options can go somewhere else, maybe a previous chapter.
2. From what I understand from my almost zero experience of rust, the match/deconstruct with a Result type will do 99% of error handling -- even though it might be verbose or ugly to some. Its also the basis for the combinators. This can be the short and simple error handling chapter.
3. The combinators are nice constructs to make code more linear looking and are convenient when working with the std library. If they are stated as an optional convenience then they become less scary. Error handling is so fundamental that I should not have to learn about combinators to do it.
What I suggest is a rearrangement of the material. The documentation itself is clear -- its just too much.
- burntsushi 10y agoInteresting. 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.
- carols10cents 10y agoI wonder if you'd like the error handling chapter in the new book [1]; it started from a base of burntsushi's blog post but we did rearrange quite a bit. Option is in another chapter now. [1] - http://rust-lang.github.io/book/ch09-00-error-handling.html http://rust-lang.github.io/book/ch09-00-error-handling.html