I'm working on a Rust wrapper for the Duktape JavaScript interpreter. In a normal use case, the call stack will look like this:
- Rust: Arbitrary application code.
- Rust: My library wrapper.
- C: The Duktape interpreter.
- Rust: My Rust code.
- Rust: Arbitrary callbacks into application code.
What happens if (5) calls panic!
? According to various Rust developers on IRC, attempting to panic!
from inside non-Rust callframes like (3) may result in undefined behavior.
But according the Rust documentation, the only way to catch a panic!
is using std::task::try
, which spawns an extra thread. There's also rustrt::unwind::try
, which cannot be nested twice within a single thread, among other restrictions.
One solution, proposed by Benjamin Herr, is to abort the process if the code in (5) panics. I've packaged his solution as abort_on_panic
, and it appears to work, for values of "work" that include "crashing the entire program, but at least not corrupting things subtly":
abort_on_panic!("cannot panic inside this block", {
panic!("something went wrong!");
});
But is a way to emulate std::task::try
without the overhead of thread/task creation?
You cannot 'catch' a
panic!
. It terminates execution of the current thread. Therefore, without spinning up a new one to isolate, it's going to terminate the thread you're in.As of Rust 1.9.0, you can use
panic::catch_unwind
to recover the error:Passing it to the next layer is just as easy with
panic::resume_unwind
: