|
|
|
|
|
|
by pornel
1216 days ago
|
|
|
Unsafe code needs to be paranoid about panics, because that’s equivalent of exception safety in C++. However, other safe Rust code doesn’t need to care that much, because it will either unwind and run destructors, or abort the program. Both are well defined and safe. Rust uses panics to signal programmer bugs, not normal error handling, so there isn’t much to do about them in the code, because actual “handling” of panics is fixing the bug. |
|
|
- Lock poisoning and dealing with locks failing to open because they’re poisoned after some other thread panics.
- The whole scoped thread thing.
- Panics across async calls have a bunch of unintuitive (but reasonable once you think through the constraints!) behaviors.
It all comes down to the same thing: a function call could return or it could panic. Even when writing safe code, you have to know what you’re doing to do in case of panic. Usually that’s just passing the panic upward*, but not always, and those behaviors aren’t well-captured in the type system. Because of that, writing truly panic-free Rust is hard to impossible.
I don’t have a better answer than the panicking system. But you do have to care even in safe code, and it is a design weakness.
* I know about panic handlers and abort-on-panic. It doesn’t change the overall point.