4 ms·

Rust also made the same mistake that Go did: it tried to appease the "exceptions are bad" crowd and ended up adding exceptions as an afterthought. I'm angry: Ru

Rust also made the same mistake that Go did: it tried to appease the "exceptions are bad" crowd and ended up adding exceptions as an afterthought. I'm angry: Rust is merely good, but with a few early tweaks, it could have been great.

kibwen 11y ago
Rust does not have exceptions, not even in the limited capacity that Go sort-of has. It's legal for a Rust implementation to translate panics into aborts, which means that they cannot be relied upon as an error-handling mechanism. Furthermore, the means to halt unwinding in Rust exists only to prevent memory unsafety from occurring when Rust is embedded in another language via the C interface, because unwinding across an FFI boundary is undefined behavior. In fact the exact mechanism used in the aforementioned role has deliberately arbitrary restrictions placed upon it in order to prevent anyone from using it as a general-purpose error-handling mechanism. Finally, the prevailing Rust culture overwhelmingly discourages using anything other than Result for error handling, to such an extreme that I've never in all my days even seen anyone attempt to "catch" a panic as an error-recovery mechanism.
- quotemstr 11y ago
  https://doc.rust-lang.org/beta/std/panic/fn.recover.html https://doc.rust-lang.org/beta/std/panic/fn.recover.html looks a lot like catch to me. That the documentation suggests not using it as "catch" is merely a political statement. While it may be legal to turn panics into abort, I doubt implementations will do that, because by doing so, you'll break programs that assume that panic recovery works. The reason Rust's standard library isn't safe against malloc failure is that propagating Error everywhere would be cumbersome; I distinctly recall rust mailing list discussions on this point. The only reason handling allocation failure has to be difficult is that the Rust people put themselves into giving into the anti-exception people. Once you allow exceptions, allocation failure becomes as easy to address as any other kind of resource exhaustion. The Rust designers made a serious error eschewing the only fully general and fully ergonomic error handling strategy we've found.
  - dbaupp 11y ago
    Implementations will do that, e.g. https://github.com/rust-lang/rfcs/pull/1513 https://github.com/rust-lang/rfcs/pull/1513 .
    - quotemstr 11y ago
      Encouraging this style of programming makes me sad.
      - kibwen 11y ago
        This isn't a style of programming, it's a compiler flag for end-users. There's a reason that GCC and Clang have the -fno-exceptions flag.
        quotemstr 11y ago
        The -fno-exceptions flag also makes me sad, because it encourages people to write libraries that are worse than they could be purely for the sake of interacting with code that chooses not to use an important feature of the language. Exception support should not be optional.
  - kibwen 11y ago
    > the Rust people put themselves into giving into the > anti-exception people It's a shame that you characterize design decisions as "giving into" the crowd instead of trying to understand why the decision might make sense in the context of Rust. Designing the error handling story was a discussion that spanned years, with dozens of discussions, many implementations, and likely hundreds of participants. > That the documentation suggests not using it as "catch" > is merely a political statement It's not just political, note the "RecoverSafe" bound on the type parameter. See https://doc.rust-lang.org/nightly/std/panic/trait.RecoverSafe.html https://doc.rust-lang.org/nightly/std/panic/trait.RecoverSaf...
jpco 11y ago
What's wrong with Rust's error-handling mechanism (namely, the `Result` type)? Generally when writing Rust, panics only come up when you actively invite them with something like an `.unwrap()` call or the `try!` macro, which is Decidedly Bad Style for anything serious.
- deleted 11y ago
  [deleted]
- kibwen 11y ago
  The `try!` macro never causes panics, it uses the `Result` type as is typical for error handling in Rust.

kibwen 11y ago

Rust does not have exceptions, not even in the limited capacity that Go sort-of has. It's legal for a Rust implementation to translate panics into aborts, which means that they cannot be relied upon as an error-handling mechanism. Furthermore, the means to halt unwinding in Rust exists only to prevent memory unsafety from occurring when Rust is embedded in another language via the C interface, because unwinding across an FFI boundary is undefined behavior. In fact the exact mechanism used in the aforementioned role has deliberately arbitrary restrictions placed upon it in order to prevent anyone from using it as a general-purpose error-handling mechanism. Finally, the prevailing Rust culture overwhelmingly discourages using anything other than Result for error handling, to such an extreme that I've never in all my days even seen anyone attempt to "catch" a panic as an error-recovery mechanism.

quotemstr 11y ago
https://doc.rust-lang.org/beta/std/panic/fn.recover.html https://doc.rust-lang.org/beta/std/panic/fn.recover.html looks a lot like catch to me. That the documentation suggests not using it as "catch" is merely a political statement. While it may be legal to turn panics into abort, I doubt implementations will do that, because by doing so, you'll break programs that assume that panic recovery works. The reason Rust's standard library isn't safe against malloc failure is that propagating Error everywhere would be cumbersome; I distinctly recall rust mailing list discussions on this point. The only reason handling allocation failure has to be difficult is that the Rust people put themselves into giving into the anti-exception people. Once you allow exceptions, allocation failure becomes as easy to address as any other kind of resource exhaustion. The Rust designers made a serious error eschewing the only fully general and fully ergonomic error handling strategy we've found.
- dbaupp 11y ago
  Implementations will do that, e.g. https://github.com/rust-lang/rfcs/pull/1513 https://github.com/rust-lang/rfcs/pull/1513 .
  - quotemstr 11y ago
    Encouraging this style of programming makes me sad.
    - kibwen 11y ago
      This isn't a style of programming, it's a compiler flag for end-users. There's a reason that GCC and Clang have the -fno-exceptions flag.
      - quotemstr 11y ago
        The -fno-exceptions flag also makes me sad, because it encourages people to write libraries that are worse than they could be purely for the sake of interacting with code that chooses not to use an important feature of the language. Exception support should not be optional.
- kibwen 11y ago
  > the Rust people put themselves into giving into the > anti-exception people It's a shame that you characterize design decisions as "giving into" the crowd instead of trying to understand why the decision might make sense in the context of Rust. Designing the error handling story was a discussion that spanned years, with dozens of discussions, many implementations, and likely hundreds of participants. > That the documentation suggests not using it as "catch" > is merely a political statement It's not just political, note the "RecoverSafe" bound on the type parameter. See https://doc.rust-lang.org/nightly/std/panic/trait.RecoverSafe.html https://doc.rust-lang.org/nightly/std/panic/trait.RecoverSaf...

jpco 11y ago

What's wrong with Rust's error-handling mechanism (namely, the `Result` type)? Generally when writing Rust, panics only come up when you actively invite them with something like an `.unwrap()` call or the `try!` macro, which is Decidedly Bad Style for anything serious.

deleted 11y ago
[deleted]
kibwen 11y ago
The `try!` macro never causes panics, it uses the `Result` type as is typical for error handling in Rust.