4 ms·
> Did Rust end up with both errors and panics because the community suppressed robust debate in the name of kindness and "safety"? Was the current approach a wa
by ssokolow 3y ago
> Did Rust end up with both errors and panics because the community suppressed robust debate in the name of kindness and "safety"? Was the current approach a way to try to make everyone happy without conflict?
I've been hanging around /r/rust and poking at other venues since at least 2013 and my understanding was that the exception-like appearance of panics arose organically from:
1. Let's have monadic error handling for catchable stuff and an ASSERT equivalent for bugs that cannot be reasonably handled.
2. Our ownership system and mutex poisoning allows us to make strong guarantees about where invalid state is observable. Let's let a thread ASSERT without taking down the whole program.
3. It'd be nice to have RAII cleanup on an ASSERT
4. It'd be nice to have automatic diagnostics on an ASSERT failure
5. Gee, it's really awkward to have to spawn a thread in order to be able to translate an ASSERT failure into an error code when we're exposing a C API from Rust code. Let's add catch_unwind. (std::panic::catch_unwind didn't get stabilized until Rust 1.9.)
The clearest expression of this is that libraries cannot opt back into unwinding when the application that depends on them sets panic=abort. If an application says "I have no need to continue with the following job/request/etc. after a programming error in a single unit of work", the libraries it depends on aren't allowed to countermand that and, if they try, it's their fault for abusing panics. Panics are overgrown ASSERTs, not an underbuilt exception system.