> But there's a lot of errors that aren't really recoverable inside a library
Aren't all propagated `Result`s examples of errors that the library itself doesn't recover from and lets the caller decide what to do? IMO, panics in libraries are for cases that are either "impossible" (`panic` as `assert`) or the library author made a judgement call that the application is also helpless in this situation (`panic` as `exit`, like OOM in most of `std`).
> you may not want to cause the code using that library to crash - perhaps your buggy component can be worked around.
That's a question of isolation! Rust libraries operate within the same process and address space as the application code. A buggy library could arbitrarily modify the application data or the process state and violate arbitrary application invariants. I'm not even talking about UB here. Just application-level invariants and assumptions.
Given this, the Rust's choice to either "abort the thread and poison held mutexes" or "abort the process" sounds very reasonable.
In other discussions, I was pointed to Erlang's "let it fail" error handling with multiple isolated processes. [The Error Model](https://joeduffyblog.com/2016/02/07/the-error-model/), which I reference in my post, also touches on this topic.
Panics in rust threads do not crash the process. Only panics in the main thread crash the process. So if you run nothing in the main thread, you can take advantage of this.
> Panics in rust threads do not crash the process.
They do on several occasions, as I mentioned in the post:
> the process still crashes if the target doesn’t support unwinding or the project is built with panic = "abort" setting.
The linked guide to error handling in Rust [1] mentions another such case:
> Even in the default unwind-on-panic configuration, causing a panic while the thread is already panicking will cause the whole program to abort. You must therefore be very careful that destructors cannot panic under any circumstance. You can check if the current thread is panicking by using the std::thread::panicking function.
Aren't all propagated `Result`s examples of errors that the library itself doesn't recover from and lets the caller decide what to do? IMO, panics in libraries are for cases that are either "impossible" (`panic` as `assert`) or the library author made a judgement call that the application is also helpless in this situation (`panic` as `exit`, like OOM in most of `std`).
> you may not want to cause the code using that library to crash - perhaps your buggy component can be worked around.
That's a question of isolation! Rust libraries operate within the same process and address space as the application code. A buggy library could arbitrarily modify the application data or the process state and violate arbitrary application invariants. I'm not even talking about UB here. Just application-level invariants and assumptions.
Given this, the Rust's choice to either "abort the thread and poison held mutexes" or "abort the process" sounds very reasonable.
In other discussions, I was pointed to Erlang's "let it fail" error handling with multiple isolated processes. [The Error Model](https://joeduffyblog.com/2016/02/07/the-error-model/), which I reference in my post, also touches on this topic.