3 ms·

We would lose lots of users from C and C++ if we mandated exceptions for error handling. The code size and complexity of unwinding is too much of a price for ma

We would lose lots of users from C and C++ if we mandated exceptions for error handling. The code size and complexity of unwinding is too much of a price for many to pay.

soulbadguy 10y ago
Not mandate them , use have them as an options where the monadic Errors types are not enough or are too cumbersome to use.
- pcwalton 10y ago
  And thereby prevent people from writing code that needs to catch errors but can't use exceptions. Won't work.
  - soulbadguy 10y ago
    I don't understand what that sentence means...
    - thristian 10y ago
      Some people don't want to use exceptions because of runtime overhead costs. If exceptions are just "an option" that a library can choose when designing its interface, then you'll get a split ecosystem: a bunch of libraries that do use exceptions for error-handling, and then a separate bunch of libraries that do the same thing, but don't use exceptions for error handling, which is wasted, redundant effort.
      - btschaegg 10y ago
        > then you'll get a split ecosystem Agreed. Point in case: Have a look at D and the discussions about their GC. I haven't kept up much about the last year, but my general impression runs down to: If you want to use their standard library. There's gonna be garbage collection. Period. If you want to avoid it, enjoy implementing its functionality all by yourself. With rust and exceptions you would likely not have a problem with the main ecosystem, but the same problem is bound to pop up with some big & famous library. Edit: Similarly, exceptions are one of the reasons C++'s SG14 exists.
- deleted 10y ago
  [deleted]
Animats 10y ago
Rust is already paying the cost of unwinding. RFC 1236 added unwinding machinery for catching panics.[1] ("A drawback of this RFC is that it can water down Rust's error handling story.") This is the expensive part of exception handling. Rust has exceptions, but they're not very good. Go also backed into adding most of the machinery for exceptions by adding catch with unwind for panics. If you're going to have the unwinding machinery, why not have real exceptions? Exceptions aren't so bad if you do them the way Python does, using a predefined exception hierarchy. Catching an exception catches everything in its subtree. Catching RuntimeError catches most of the things one can induce from outside the program. Python's WITH statement also has one of the few mechanisms which can gracefully handle an error on releasing a resource. Exceptions in C++, Java, and Javascript are more troublesome. [1] https://github.com/rust-lang/rfcs/blob/master/text/1236-stabilize-catch-panic.md https://github.com/rust-lang/rfcs/blob/master/text/1236-stab...
- dbaupp 10y ago
  You have talked about Python's exception scheme before, and been rebuffed before (it is too dynamic to use pervasively in a systems language), please be more specific, and also have the minimum grace to not repeat incorrect things. In any case, panics are not guaranteed to unwind or be catchable: they can be turned into aborts (yes, on the stable compiler). This means an arbitrary library using them for recoverable error handling is incorrect.
  - Animats 10y ago
    What dynamism? An exception hierarchy just requires a type hierarchy, and Rust has enough inheritance for that. Rust has some dynamic dispatch, although it's not clear if the mechanism for trait objects [1] can implement an exception hierarchy cleanly. A WITH clause mechanism implies no dynamism. Please be more specific with your complaints. Thanks. [1] https://doc.rust-lang.org/book/trait-objects.html https://doc.rust-lang.org/book/trait-objects.html
    - dbaupp 10y ago
      Firstly, "just" determining membership of a value within a type hierarchy requires far more dynamism than zero. Given a fairly arbitrary type-erased value x, how do you tell if its type implements some fairly arbitrary trait T? This hierarchy presumably has to be open, which makes the problem harder. Additionally, unless one is using explicitly typed exceptions (i.e. Java-style checked exceptions, very much unlike Python), it requires allocations, as it's not possible to statically determine the size of the error object to be returned. Similarly, from an assurance/reliability point of view, the dynamically typed nature of non-checked exceptions is unfortunate. (These second two are, I believe, the points I made last time we discussed Python's exceptions.)
fjrieiekd 10y ago
There's also Swift's approach, which looks like exceptions but is really similar to Rust's approach under the hood. Swift also requires failable calls to be prefixed by "try" which makes them even easier to spot than the postfix "?" that Rust uses.

We would lose lots of users from C and C++ if we mandated exceptions for error handling. The code size and complexity of unwinding is too much of a price for many to pay.

soulbadguy 10y ago

Not mandate them , use have them as an options where the monadic Errors types are not enough or are too cumbersome to use.

pcwalton 10y ago
And thereby prevent people from writing code that needs to catch errors but can't use exceptions. Won't work.
- soulbadguy 10y ago
  I don't understand what that sentence means...
  - thristian 10y ago
    Some people don't want to use exceptions because of runtime overhead costs. If exceptions are just "an option" that a library can choose when designing its interface, then you'll get a split ecosystem: a bunch of libraries that do use exceptions for error-handling, and then a separate bunch of libraries that do the same thing, but don't use exceptions for error handling, which is wasted, redundant effort.
    - btschaegg 10y ago
      > then you'll get a split ecosystem Agreed. Point in case: Have a look at D and the discussions about their GC. I haven't kept up much about the last year, but my general impression runs down to: If you want to use their standard library. There's gonna be garbage collection. Period. If you want to avoid it, enjoy implementing its functionality all by yourself. With rust and exceptions you would likely not have a problem with the main ecosystem, but the same problem is bound to pop up with some big & famous library. Edit: Similarly, exceptions are one of the reasons C++'s SG14 exists.
deleted 10y ago
[deleted]

Animats 10y ago

Rust is already paying the cost of unwinding. RFC 1236 added unwinding machinery for catching panics.[1] ("A drawback of this RFC is that it can water down Rust's error handling story.") This is the expensive part of exception handling. Rust has exceptions, but they're not very good. Go also backed into adding most of the machinery for exceptions by adding catch with unwind for panics. If you're going to have the unwinding machinery, why not have real exceptions? Exceptions aren't so bad if you do them the way Python does, using a predefined exception hierarchy. Catching an exception catches everything in its subtree. Catching RuntimeError catches most of the things one can induce from outside the program. Python's WITH statement also has one of the few mechanisms which can gracefully handle an error on releasing a resource. Exceptions in C++, Java, and Javascript are more troublesome. [1] https://github.com/rust-lang/rfcs/blob/master/text/1236-stabilize-catch-panic.md https://github.com/rust-lang/rfcs/blob/master/text/1236-stab...

dbaupp 10y ago
You have talked about Python's exception scheme before, and been rebuffed before (it is too dynamic to use pervasively in a systems language), please be more specific, and also have the minimum grace to not repeat incorrect things. In any case, panics are not guaranteed to unwind or be catchable: they can be turned into aborts (yes, on the stable compiler). This means an arbitrary library using them for recoverable error handling is incorrect.
- Animats 10y ago
  What dynamism? An exception hierarchy just requires a type hierarchy, and Rust has enough inheritance for that. Rust has some dynamic dispatch, although it's not clear if the mechanism for trait objects [1] can implement an exception hierarchy cleanly. A WITH clause mechanism implies no dynamism. Please be more specific with your complaints. Thanks. [1] https://doc.rust-lang.org/book/trait-objects.html https://doc.rust-lang.org/book/trait-objects.html
  - dbaupp 10y ago
    Firstly, "just" determining membership of a value within a type hierarchy requires far more dynamism than zero. Given a fairly arbitrary type-erased value x, how do you tell if its type implements some fairly arbitrary trait T? This hierarchy presumably has to be open, which makes the problem harder. Additionally, unless one is using explicitly typed exceptions (i.e. Java-style checked exceptions, very much unlike Python), it requires allocations, as it's not possible to statically determine the size of the error object to be returned. Similarly, from an assurance/reliability point of view, the dynamically typed nature of non-checked exceptions is unfortunate. (These second two are, I believe, the points I made last time we discussed Python's exceptions.)

fjrieiekd 10y ago

There's also Swift's approach, which looks like exceptions but is really similar to Rust's approach under the hood. Swift also requires failable calls to be prefixed by "try" which makes them even easier to spot than the postfix "?" that Rust uses.