3 ms·

The hacks needed to avoid the need for exceptions are uglier than exceptions. I felt like this when I read the scary documentation: https://doc.rust-lang.o

• steveklabnik 10y ago
  The next iteration of the book will have a much more cut-down version of this; this chapter is _so_ thorough, but also gives you the impression that it's more complex than it has to be due to said thouroughness.
• burntsushi 10y ago
  > introduces non-essential craziness without warning. Like what? (Disclaimer: I originally wrote that chapter as a blog post[1], so I'm curious to hear what I could have cut out. I tried to find things to cut, but given my target audience, I couldn't find anything substantial.) [1] - http://blog.burntsushi.net/rust-error-handling/ http://blog.burntsushi.net/rust-error-handling/
  • 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 ago
      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
  Rust now has not just "panic", but "panic::recover", with unwinding. That's an exception system. It's just one with weak syntax and semantics. Go went down this route, too. In the beginning, Go errors were fatal. Then the Go crowd added "recover". With unwinding. Both languages now have the heavy machinery for exceptions without full language support for them. The discussions of this on Rust mailing lists show much unhappiness with the situation. If you don't put in exceptions, you seem to end up re-inventing "longjmp".
  • Manishearth 10y ago
    Panic recovery and panics can be disabled, and often are. Libraries are not supposed to rely on their existence. Thus these are not a form of exceptions ; they can't be used as such. Their purpose is to recover from panics when embedding Rust in code written in other languages, where you don't want the panic to try and cross the ffi boundary (or to stop applications that should never crash from crashing at the toplevel, or for better reporting before a crash). Many FFI-based applications turn panics into aborts anyway. Firefox does. The unwind-recovery functionality in Rust is just enough to get you these useful features if you need them (zero cost if you don't; turn them into aborts), without needing a full on exception system. The reason Rust avoids an exception system isn't the cost of unwinding, it's because it considers exceptions to be an inferior pattern compared to return value based / monadic error handling. Rust doesn't have a mailing list anymore. I haven't seen much annoyance with panic recovery. There used to be some with panics in general because in the past they couldn't be turned off or recovered from without a new thread, but this has been addressed for ages with panic=abort and recovery. What the hell are you talking about?
  • pcwalton 10y ago
    Panics can be turned into aborts, and a lot of Rust apps do this. It is therefore poor practice, and unfriendly to your users, to publish a library that relies on unwinding. No popular library I know of relies on it.