7 ms·

No custom allocator can make a task that fails to allocate gracefully report an error. Rust's error handling design is just terrible, and mostly a consequence o

No custom allocator can make a task that fails to allocate gracefully report an error. Rust's error handling design is just terrible, and mostly a consequence of eschewing exceptions. Had Rust opted for exceptions, it'd be a much better, and actually usable, language. Rust's terribly error-handling strategy is the chief reason not to use it.

steveklabnik 11y ago
> No custom allocator can make the task gracefully report failure > instead of panicing. So, first of all, "custom allocators" means two things: * overloading the allocator that's used by liballoc, and the crates that depend on it, like libstd * other allocators entirely The first is described here: https://doc.rust-lang.org/book/custom-allocators.html https://doc.rust-lang.org/book/custom-allocators.html And the second is still in RFCs: https://github.com/rust-lang/rfcs/pull/1398 https://github.com/rust-lang/rfcs/pull/1398 Both of these things are not yet stable. The second does, in fact, give you the ability to return an error code, by returning a Result. However, on top of that, I don't see how > mostly a consequence of eschewing exceptions. and > No custom allocator can make the task gracefully report failure > instead of panicing. Work together. Or rather, why is panic-ing bad, but an exception good?
- deleted 11y ago
  [deleted]
- quotemstr 11y ago
  > why is panic-ing bad, but an exception good? Because the Rust people don't believe in making "catch" a first-class primitive in the language, and in fact, fully support a runtime option to turn all panics into aborts. Even if abort-on-panic were to be killed as a legal mode of operation, and even if the stigma were to be removed from std::panic::recover, we'd still be left with a language with two error handling strategies and endless programmer confusion over which to use. Rust's designers have done permanent damage to the language by not making exceptions the primary error reporting mechanism available to programmers, and it's not a mistake they can undo now.
  - Rusky 11y ago
    Exceptions can be turned into aborts in C++ as well, and are in many types of programs, because exceptions do have downsides for some problem domains. If Rust forced exceptions on everyone, there'd be people complaining about that just like you're complaining now. I see the split between `Result` and `panic!` as more like Java's split between checked and runtime exceptions, except `Result` is much more usable than checked exceptions because it's part of the main data flow path, and so can use method chaining combinators instead of unwieldy try/catch blocks. OOM in Java is, like in Rust, not a checked exception, because it's not something you'd want to handle everywhere it can happen, but rather something to propagate up the stack transparently.
    - quotemstr 11y ago
      > Exceptions can be turned into aborts in C++ as well, No you can't. -fno-exceptions does not appear in the C++ standard. You can write a compiler for any language. C++-that-aborts-on-throw is not C++, although, sure, it's closely related. The ability to turn off C++ exceptions was a temporary workaround for compiler deficiencies in the 1990s that snowballed into an extremely harmful schism that's still doing tremendous damage to the C++ community. The difference between -fno-exceptions and Rust's abort-on-panic is that the former is an unofficial, disgusting hack, while the latter is getting full official support for some reason.
      - Rusky 11y ago
        That's not a very meaningful distinction to make- Rust doesn't even have a standard right now. Besides, -fno-exceptions is quite useful today, not just because of 90s compiler deficiencies, and is pretty well-supported by compilers.
        quotemstr 11y ago
        The existence of -fno-exceptions means that library authors either using the language as intended, and accept losing a portion of their potential user base, or write less-than-optimally elegant and clear code, which punishes everyone, so a few can turn off a core feature of the language. It fragments the community.
Manishearth 11y ago
> and mostly a consequence of eschewing exceptions. A panic is the same thing as an exception. If you want to catch a panic, use recover(), it's meant to be used exactly for these end-of-the-world panic scenarios (and for FFI/etc). You can plug in a custom allocator that panics on OOM (I think the standard one aborts). As Steve mentioned, custom allocators can mean two things. The type that exists in rust today is one where you can make OOM panic, but not have allocation methods return Result. A planned extension will let you have allocators with different semantics entirely work with stdlib types (via defaulted type parameters); and this will let you use regular error handling with stdlib types too.
- quotemstr 11y ago
  > A planned extension will let you have allocators with different semantics entirely work with stdlib types And what about all the code that doesn't? It's because so much code exists that's completely oblivious to the possibility of these stdlib functions failing that I don't think that merely adding the option to do the right thing is good enough. The existing failure-oblivious APIs need to be explicitly deprecated. The only ways to redeem Rust is to either support exceptions as first-class citizens with mandatory runtime support or to convert all existing allocating stdlib functions to return Result and mark all the existing failure-oblivious ones as being as deprecated as gets(3) in C.
  - Rusky 11y ago
    Even C++ doesn't have mandatory exception support, and even Rust can catch panics from failure-oblivious code.
    - quotemstr 11y ago
      > Even C++ doesn't have mandatory exception support Yes it does. That some compilers provide a way to disable mandatory language features is no argument. > even Rust can catch panics from failure-oblivious code. Not while maintaining that code's invariants it can't.
pcwalton 11y ago
> No custom allocator can make a task that fails to allocate gracefully report an error. Yes, you can. You can panic the thread, and you can recover from panics. But honestly this is never enough to gracefully recover from OOM. I can't think of any software that uses exceptions to gracefully recover from OOM (i.e. without crashing the process) in a way that works. How many Java applications do you see that catch OutOfMemoryError on a fine-grained level? > Had Rust opted for exceptions, it'd be a much better, and actually usable, language. Rust's terribly error-handling strategy is the chief reason not to use it. It's hyperbolic to call Rust's error handling strategy not "actually usable". I use it every day and never have any issues with it.
- quotemstr 11y ago
  > How many Java applications do you see that catch OutOfMemoryError on a fine-grained level? I wrote exactly that sort of code, in Java, last week.
  - pcwalton 11y ago
    I believe you that you do. That doesn't change the fact that few people actually do it or need to do it. There are many more people who think they need to recover from OOM but actually don't and would be better off if they didn't try. (There have been many security vulnerabilities that have resulted from attempting to handle OOM gracefully that wouldn't have been an issue if malloc just aborted the process.)
    - quotemstr 11y ago
      I agree with you, but a general-purpose systems programming language needs to let _me_ make that determination. It can't abort on my behalf for my own good. It's depressing that Java, of all things, does a better job in this respect than Rust. And we probably shouldn't be writing so much software in general-purpose systems programming languages.
      - pcwalton 11y ago

steveklabnik 11y ago

> No custom allocator can make the task gracefully report failure > instead of panicing. So, first of all, "custom allocators" means two things: * overloading the allocator that's used by liballoc, and the crates that depend on it, like libstd * other allocators entirely The first is described here: https://doc.rust-lang.org/book/custom-allocators.html https://doc.rust-lang.org/book/custom-allocators.html And the second is still in RFCs: https://github.com/rust-lang/rfcs/pull/1398 https://github.com/rust-lang/rfcs/pull/1398 Both of these things are not yet stable. The second does, in fact, give you the ability to return an error code, by returning a Result. However, on top of that, I don't see how > mostly a consequence of eschewing exceptions. and > No custom allocator can make the task gracefully report failure > instead of panicing. Work together. Or rather, why is panic-ing bad, but an exception good?

deleted 11y ago
[deleted]
quotemstr 11y ago
> why is panic-ing bad, but an exception good? Because the Rust people don't believe in making "catch" a first-class primitive in the language, and in fact, fully support a runtime option to turn all panics into aborts. Even if abort-on-panic were to be killed as a legal mode of operation, and even if the stigma were to be removed from std::panic::recover, we'd still be left with a language with two error handling strategies and endless programmer confusion over which to use. Rust's designers have done permanent damage to the language by not making exceptions the primary error reporting mechanism available to programmers, and it's not a mistake they can undo now.
- Rusky 11y ago
  Exceptions can be turned into aborts in C++ as well, and are in many types of programs, because exceptions do have downsides for some problem domains. If Rust forced exceptions on everyone, there'd be people complaining about that just like you're complaining now. I see the split between `Result` and `panic!` as more like Java's split between checked and runtime exceptions, except `Result` is much more usable than checked exceptions because it's part of the main data flow path, and so can use method chaining combinators instead of unwieldy try/catch blocks. OOM in Java is, like in Rust, not a checked exception, because it's not something you'd want to handle everywhere it can happen, but rather something to propagate up the stack transparently.
  - quotemstr 11y ago
    > Exceptions can be turned into aborts in C++ as well, No you can't. -fno-exceptions does not appear in the C++ standard. You can write a compiler for any language. C++-that-aborts-on-throw is not C++, although, sure, it's closely related. The ability to turn off C++ exceptions was a temporary workaround for compiler deficiencies in the 1990s that snowballed into an extremely harmful schism that's still doing tremendous damage to the C++ community. The difference between -fno-exceptions and Rust's abort-on-panic is that the former is an unofficial, disgusting hack, while the latter is getting full official support for some reason.
    - Rusky 11y ago
      That's not a very meaningful distinction to make- Rust doesn't even have a standard right now. Besides, -fno-exceptions is quite useful today, not just because of 90s compiler deficiencies, and is pretty well-supported by compilers.
      - quotemstr 11y ago
        The existence of -fno-exceptions means that library authors either using the language as intended, and accept losing a portion of their potential user base, or write less-than-optimally elegant and clear code, which punishes everyone, so a few can turn off a core feature of the language. It fragments the community.

Manishearth 11y ago

> and mostly a consequence of eschewing exceptions. A panic is the same thing as an exception. If you want to catch a panic, use recover(), it's meant to be used exactly for these end-of-the-world panic scenarios (and for FFI/etc). You can plug in a custom allocator that panics on OOM (I think the standard one aborts). As Steve mentioned, custom allocators can mean two things. The type that exists in rust today is one where you can make OOM panic, but not have allocation methods return Result. A planned extension will let you have allocators with different semantics entirely work with stdlib types (via defaulted type parameters); and this will let you use regular error handling with stdlib types too.

quotemstr 11y ago
> A planned extension will let you have allocators with different semantics entirely work with stdlib types And what about all the code that doesn't? It's because so much code exists that's completely oblivious to the possibility of these stdlib functions failing that I don't think that merely adding the option to do the right thing is good enough. The existing failure-oblivious APIs need to be explicitly deprecated. The only ways to redeem Rust is to either support exceptions as first-class citizens with mandatory runtime support or to convert all existing allocating stdlib functions to return Result and mark all the existing failure-oblivious ones as being as deprecated as gets(3) in C.
- Rusky 11y ago
  Even C++ doesn't have mandatory exception support, and even Rust can catch panics from failure-oblivious code.
  - quotemstr 11y ago
    > Even C++ doesn't have mandatory exception support Yes it does. That some compilers provide a way to disable mandatory language features is no argument. > even Rust can catch panics from failure-oblivious code. Not while maintaining that code's invariants it can't.

pcwalton 11y ago

> No custom allocator can make a task that fails to allocate gracefully report an error. Yes, you can. You can panic the thread, and you can recover from panics. But honestly this is never enough to gracefully recover from OOM. I can't think of any software that uses exceptions to gracefully recover from OOM (i.e. without crashing the process) in a way that works. How many Java applications do you see that catch OutOfMemoryError on a fine-grained level? > Had Rust opted for exceptions, it'd be a much better, and actually usable, language. Rust's terribly error-handling strategy is the chief reason not to use it. It's hyperbolic to call Rust's error handling strategy not "actually usable". I use it every day and never have any issues with it.

quotemstr 11y ago
> How many Java applications do you see that catch OutOfMemoryError on a fine-grained level? I wrote exactly that sort of code, in Java, last week.
- pcwalton 11y ago
  I believe you that you do. That doesn't change the fact that few people actually do it or need to do it. There are many more people who think they need to recover from OOM but actually don't and would be better off if they didn't try. (There have been many security vulnerabilities that have resulted from attempting to handle OOM gracefully that wouldn't have been an issue if malloc just aborted the process.)
  - quotemstr 11y ago
    I agree with you, but a general-purpose systems programming language needs to let _me_ make that determination. It can't abort on my behalf for my own good. It's depressing that Java, of all things, does a better job in this respect than Rust. And we probably shouldn't be writing so much software in general-purpose systems programming languages.
    - pcwalton 11y ago