问题
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?
回答1:
As of Rust 1.9.0, you can use panic::catch_unwind to recover the error:
use std::panic;
fn main() {
let result = panic::catch_unwind(|| {
panic!("oh no!");
});
assert!(result.is_err());
}
Passing it to the next layer is just as easy with panic::resume_unwind:
use std::panic;
fn main() {
let result = panic::catch_unwind(|| {
panic!("oh no!");
});
if let Err(e) = result {
panic::resume_unwind(e);
}
}
回答2:
Editor's note: This answer predates Rust 1.0 and is no longer necessarily accurate. Other answers still contain valuable information.
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.
来源:https://stackoverflow.com/questions/27384824/catching-panic-when-rust-called-from-c-ffi-without-spawning-threads