3 ms·

Yes, but it's still progress toward the inevitable end result of traditional C++-style exceptions. That's the inevitable end state because the traditional excep

Yes, but it's still progress toward the inevitable end result of traditional C++-style exceptions. That's the inevitable end state because the traditional exception model is simply the best one.

kibwen 11y ago
> the inevitable It's not inevitable in the slightest. Rust made a conscious effort to avoid exceptions for good reasons, and there's no reason to suspect that Rust will suddenly pivot on its heel in the opposite direction. Despite your attempts to paint this as a slippery slope, the unwinding-halting mechanisms are there to provide a safety net for people writing Rust libraries that expose C ABIs so that library code can fail gracefully without taking down the parent process. > the traditional exception model is simply the best one Citation needed. :P The Rust community has long since embraced Result-based error handling; I don't hear calls for adding exceptions nearly as often as you seem to suspect. As to "inevitability", you'll be sad to learn that Rust plans on adding a mechanism that will enable applications to make panics impossible to catch, by disabling unwinding entirely and translating all panics to outright aborts (some argue that this should even be the default behavior of Rust code, but that won't happen any time soon). And considering that Mozilla disables exceptions entirely in Firefox, I see no reason they would pressure the Rust developers to add exceptions to Rust. You seem to be taking Rust's approach to error handling far too personally. :P It is not Rust's position that exceptions are a blight that must be scoured from the face of the Earth. It is merely Rust's position that there are easier ways to achieve concise and composable error handling for its intended domain, given Rust's other features and safety mechanisms.
- quotemstr 11y ago
  > Despite your attempts to paint this as a slippery slope It is, though. I'm not[1][2] the only one who very much prefers the exceptional model of error handling. Once the ability to catch exceptions exists, people like me are going to write exceptional code. [1] https://github.com/rust-lang/rfcs/pull/1236#issuecomment-127793407 https://github.com/rust-lang/rfcs/pull/1236#issuecomment-127... [2] https://github.com/rust-lang/rfcs/pull/1236#issuecomment-128834789 https://github.com/rust-lang/rfcs/pull/1236#issuecomment-128... > > the traditional exception model is simply the best one > Citation needed. :P When Java, Python, C++, and Common Lisp all converge on the same thing, maybe that thing has something going for it. Part of my claim is subjective, but I've worked on systems that used everything from abort to error codes to tagged unions to exceptions for error reporting, and I've found the exceptional code by far the easiest to work with. In exceptional code, I can write foo().bar().qux() even though foo, bar, and qux can all fail, and without any extra syntactic noise. > by disabling unwinding entirely and translating all panics to outright aborts I believe that's a mistake: it's a reprise of the -fno-exceptions debacle of the C++ world, where the ecosystem is fragmented due to fundamental disagreements on the correct error handling strategy. You'll get into a situation where some components rely on panics being hard aborts for correctness and other components rely on non-aborting panics for error handling. > And considering that Mozilla disables exceptions entirely in Firefox, I see no reason they would pressure the Rust developers to add exceptions to Rust. Rust is probably a fine Servo implementation language. Tellingly, Mozilla also uses an infallible memory allocator. I merely believe that Rust's design choices for allocation failure and error handling lead to it being a losing contender when compared to modern C++ for general-purpose systems programming.
  - kibwen 11y ago
    > Once the ability to catch exceptions exists, people like > me are going to write exceptional code. By all means, go ahead. :) Application code is free to do whatever it wants, and godspeed to you. Meanwhile, the restrictions on the catch API will be sufficiently onerous that library authors will continue to favor Result-based error-handling for their public APIs (to say nothing of the fact that some of their users may have opted to turn panics into aborts). > You'll get into a situation where some components rely on panics > being hard aborts for correctness and other components rely on > non-aborting panics for error handling. Indeed, this is precisely why Rust decided to ship 1.0 with unwinding enabled by default, much to the consternation of those who wished unwinding to be excised from the language entirely. The language is defined such that if your personal `unsafe` blocks fail to consider exception safety, you run the risk of undefined behavior and thereby forfeit Rust's guaranteed safety mechanisms: http://doc.rust-lang.org/nightly/nomicon/exception-safety.html http://doc.rust-lang.org/nightly/nomicon/exception-safety.ht... . Meanwhile, the fact that catching unwinding is all but unusable as anything other than a failsafe of last resort (and even then is only intended to prevent a total abort and/or undefined behavior) means that no library is going to resort to non-aborting panics for error handling, as mentioned previously.
    - quotemstr 11y ago
      > library authors will continue to favor Result-based error-handling for their public APIs Except for the library authors who opt to write in C++ instead, of course. If you have to deliberately make a feature of your environment difficult to use, you're optimizing for the wrong thing. The Java experience shows that bad programmers will write bad code no matter how many safeguards you try to add to the language, so the only worthwhile "speed bumps" are those that help people who know what they're doing not accidentally shoot themselves in the foot. I cannot imagine an exception-catch block appearing in my code by accident. Quite a bit of the discussion in the threads you mentioned has to do with flagging code as "requiring review" and adding "speed bumps" for "potentially troublesome" code. That's very worrisome, as it indicates that at least some members of the Rust community favor the Java-esque sandbox model of safety over the safety-catch model. C++ has many flaws, but at least it never makes me feel like the language designers thought I need to be protected from myself.

Yes, but it's still progress toward the inevitable end result of traditional C++-style exceptions. That's the inevitable end state because the traditional exception model is simply the best one.

kibwen 11y ago

> the inevitable It's not inevitable in the slightest. Rust made a conscious effort to avoid exceptions for good reasons, and there's no reason to suspect that Rust will suddenly pivot on its heel in the opposite direction. Despite your attempts to paint this as a slippery slope, the unwinding-halting mechanisms are there to provide a safety net for people writing Rust libraries that expose C ABIs so that library code can fail gracefully without taking down the parent process. > the traditional exception model is simply the best one Citation needed. :P The Rust community has long since embraced Result-based error handling; I don't hear calls for adding exceptions nearly as often as you seem to suspect. As to "inevitability", you'll be sad to learn that Rust plans on adding a mechanism that will enable applications to make panics impossible to catch, by disabling unwinding entirely and translating all panics to outright aborts (some argue that this should even be the default behavior of Rust code, but that won't happen any time soon). And considering that Mozilla disables exceptions entirely in Firefox, I see no reason they would pressure the Rust developers to add exceptions to Rust. You seem to be taking Rust's approach to error handling far too personally. :P It is not Rust's position that exceptions are a blight that must be scoured from the face of the Earth. It is merely Rust's position that there are easier ways to achieve concise and composable error handling for its intended domain, given Rust's other features and safety mechanisms.

quotemstr 11y ago
> Despite your attempts to paint this as a slippery slope It is, though. I'm not[1][2] the only one who very much prefers the exceptional model of error handling. Once the ability to catch exceptions exists, people like me are going to write exceptional code. [1] https://github.com/rust-lang/rfcs/pull/1236#issuecomment-127793407 https://github.com/rust-lang/rfcs/pull/1236#issuecomment-127... [2] https://github.com/rust-lang/rfcs/pull/1236#issuecomment-128834789 https://github.com/rust-lang/rfcs/pull/1236#issuecomment-128... > > the traditional exception model is simply the best one > Citation needed. :P When Java, Python, C++, and Common Lisp all converge on the same thing, maybe that thing has something going for it. Part of my claim is subjective, but I've worked on systems that used everything from abort to error codes to tagged unions to exceptions for error reporting, and I've found the exceptional code by far the easiest to work with. In exceptional code, I can write foo().bar().qux() even though foo, bar, and qux can all fail, and without any extra syntactic noise. > by disabling unwinding entirely and translating all panics to outright aborts I believe that's a mistake: it's a reprise of the -fno-exceptions debacle of the C++ world, where the ecosystem is fragmented due to fundamental disagreements on the correct error handling strategy. You'll get into a situation where some components rely on panics being hard aborts for correctness and other components rely on non-aborting panics for error handling. > And considering that Mozilla disables exceptions entirely in Firefox, I see no reason they would pressure the Rust developers to add exceptions to Rust. Rust is probably a fine Servo implementation language. Tellingly, Mozilla also uses an infallible memory allocator. I merely believe that Rust's design choices for allocation failure and error handling lead to it being a losing contender when compared to modern C++ for general-purpose systems programming.
- kibwen 11y ago
  > Once the ability to catch exceptions exists, people like > me are going to write exceptional code. By all means, go ahead. :) Application code is free to do whatever it wants, and godspeed to you. Meanwhile, the restrictions on the catch API will be sufficiently onerous that library authors will continue to favor Result-based error-handling for their public APIs (to say nothing of the fact that some of their users may have opted to turn panics into aborts). > You'll get into a situation where some components rely on panics > being hard aborts for correctness and other components rely on > non-aborting panics for error handling. Indeed, this is precisely why Rust decided to ship 1.0 with unwinding enabled by default, much to the consternation of those who wished unwinding to be excised from the language entirely. The language is defined such that if your personal `unsafe` blocks fail to consider exception safety, you run the risk of undefined behavior and thereby forfeit Rust's guaranteed safety mechanisms: http://doc.rust-lang.org/nightly/nomicon/exception-safety.html http://doc.rust-lang.org/nightly/nomicon/exception-safety.ht... . Meanwhile, the fact that catching unwinding is all but unusable as anything other than a failsafe of last resort (and even then is only intended to prevent a total abort and/or undefined behavior) means that no library is going to resort to non-aborting panics for error handling, as mentioned previously.
  - quotemstr 11y ago
    > library authors will continue to favor Result-based error-handling for their public APIs Except for the library authors who opt to write in C++ instead, of course. If you have to deliberately make a feature of your environment difficult to use, you're optimizing for the wrong thing. The Java experience shows that bad programmers will write bad code no matter how many safeguards you try to add to the language, so the only worthwhile "speed bumps" are those that help people who know what they're doing not accidentally shoot themselves in the foot. I cannot imagine an exception-catch block appearing in my code by accident. Quite a bit of the discussion in the threads you mentioned has to do with flagging code as "requiring review" and adding "speed bumps" for "potentially troublesome" code. That's very worrisome, as it indicates that at least some members of the Rust community favor the Java-esque sandbox model of safety over the safety-catch model. C++ has many flaws, but at least it never makes me feel like the language designers thought I need to be protected from myself.