3 ms·

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, ho

by 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.)

Animats 10y ago
Having to allocate memory while processing an exception probably isn't a big deal, since Rust does not claim to be able to operate in an out-of-memory condition. Besides, unwinding already causes allocation: "We'll also need a way to handle out-of-memory (OOM) conditions. The standard library calls the abort intrinsic, which just calls an illegal instruction to crash the whole program. The reason we abort and don't panic is because unwinding can cause allocations to happen, and that seems like a bad thing to do when your allocator just came back with "hey I don't have any more memory"."[1] [1] https://doc.rust-lang.org/nomicon/vec-alloc.html https://doc.rust-lang.org/nomicon/vec-alloc.html
- dbaupp 10y ago
  > Having to allocate memory while processing an exception probably isn't a big deal, since Rust does not claim to be able to operate in an out-of-memory condition Allocating is definitely a big deal for a pervasive error handling! For instance, parsing a number might not succeed. Both the actual parsing and the failure cases are cheap, but not if the latter has to be indicated by allocating and unwinding and doing a pile of the dynamic checks up the stack. Additionally, whether the language is able to operate in OOM isn't the only reason to choose an error handling scheme. However, even if it was, I don't think it applies directly to Rust: Rust-the-language (and Rust-the-core-library) can operate in an OOM condition, e.g. people run Rust code without needing a dynamic allocator at all. You are correct that some parts of the standard library don't handle OOM, but, using exceptions pervasively means that there is one error handling scheme for things that can rely on having an OS/malloc and one for things that don't need them. > Besides, unwinding already causes allocation Yes, and that is one reason why unwinding is not used as a pervasive error handling scheme in Rust: there are various fairly fundamental problems with it. It is one of the reasons why panics can be switched to abort.
  - soulbadguy 10y ago
    > Allocating is definitely a big deal for a pervasive error handling! Exceptions are not meant for "pervasive error", they are for exceptional execution paths. If an execution path is frequent enough, wether it's an "error" or not, then it should not be an exception. I think this is the part of the argument that the "no exception camp" usually misses : there are multi type of errors (recoverable vs fatal, frequent vs unfrequent, expected vs unexpected), having exception is not about using exceptions for all of them
    - steveklabnik 10y ago
      To be fair to the "no exception" camp, they do see that there are multiple kinds of errors: they partition them into recoverable errors and unrecoverable errors.
    - poopsicle 10y ago
      And yet the bulk of this thread was in reference to python where exceptions are the pervasive scheme.
    - dbaupp 10y ago
      As the sibling points out, this is in the context of the suggestion of using Python's approach, where exceptions are not just pervasive, they are so pervasive they're used for non-errors/control flow (e.g. StopIteration).

by dbaupp 10y ago

Animats 10y ago

Having to allocate memory while processing an exception probably isn't a big deal, since Rust does not claim to be able to operate in an out-of-memory condition. Besides, unwinding already causes allocation: "We'll also need a way to handle out-of-memory (OOM) conditions. The standard library calls the abort intrinsic, which just calls an illegal instruction to crash the whole program. The reason we abort and don't panic is because unwinding can cause allocations to happen, and that seems like a bad thing to do when your allocator just came back with "hey I don't have any more memory"."[1] [1] https://doc.rust-lang.org/nomicon/vec-alloc.html https://doc.rust-lang.org/nomicon/vec-alloc.html

dbaupp 10y ago
> Having to allocate memory while processing an exception probably isn't a big deal, since Rust does not claim to be able to operate in an out-of-memory condition Allocating is definitely a big deal for a pervasive error handling! For instance, parsing a number might not succeed. Both the actual parsing and the failure cases are cheap, but not if the latter has to be indicated by allocating and unwinding and doing a pile of the dynamic checks up the stack. Additionally, whether the language is able to operate in OOM isn't the only reason to choose an error handling scheme. However, even if it was, I don't think it applies directly to Rust: Rust-the-language (and Rust-the-core-library) can operate in an OOM condition, e.g. people run Rust code without needing a dynamic allocator at all. You are correct that some parts of the standard library don't handle OOM, but, using exceptions pervasively means that there is one error handling scheme for things that can rely on having an OS/malloc and one for things that don't need them. > Besides, unwinding already causes allocation Yes, and that is one reason why unwinding is not used as a pervasive error handling scheme in Rust: there are various fairly fundamental problems with it. It is one of the reasons why panics can be switched to abort.
- soulbadguy 10y ago
  > Allocating is definitely a big deal for a pervasive error handling! Exceptions are not meant for "pervasive error", they are for exceptional execution paths. If an execution path is frequent enough, wether it's an "error" or not, then it should not be an exception. I think this is the part of the argument that the "no exception camp" usually misses : there are multi type of errors (recoverable vs fatal, frequent vs unfrequent, expected vs unexpected), having exception is not about using exceptions for all of them
  - steveklabnik 10y ago
    To be fair to the "no exception" camp, they do see that there are multiple kinds of errors: they partition them into recoverable errors and unrecoverable errors.
  - poopsicle 10y ago
    And yet the bulk of this thread was in reference to python where exceptions are the pervasive scheme.
  - dbaupp 10y ago
    As the sibling points out, this is in the context of the suggestion of using Python's approach, where exceptions are not just pervasive, they are so pervasive they're used for non-errors/control flow (e.g. StopIteration).