Lib.rs

文档.

当前状态

该crate已基本过时。对于几乎所有用例，您应该改为将以下内容添加到您的Cargo.toml文件中

[profile]
panic = 'abort'

该crate仍然被动维护，以服务于少数一些不适用panic = "abort"的情况。如果您需要支持Rust 1.0.0或更高版本，请使用1.x版本的abort_on_panic。如果您需要支持Rust 1.22.1或更高版本，请使用2.x版本的abort_on_panic。

将继续接受错误修复的PR，但当前没有计划进行未来的更改。

概览（旧文档）

当从C调用Rust代码时，调用panic!是不安全的。这样做可能会导致不安全的行为。但是当调用用户定义的函数时，我们有时需要强制执行这些规则。

要使用此库，请将以下内容添加到您的Cargo.toml文件中

[dependencies]
abort_on_panic = "*"

当在不方便的位置发生panic!时，您可以自动执行abort进程

#![feature(phase)]
#[phase(plugin, link)] extern crate abort_on_panic;

pub fn main() {
    let result = abort_on_panic!({
        "value"
    });
    assert_eq!("value", result);

    fn oops() {
        panic!("Uh oh.");
    }
    
    abort_on_panic!({
        oops();
    });
}

动机

我正在开发一个Duktape JavaScript解释器的Rust包装器。在正常情况下，调用栈将如下所示

1. Rust: 任意应用程序代码。
2. Rust: 我的库包装器。
3. C: Duktape解释器。
4. Rust: 我的Rust代码。
5. Rust: 随机回调到应用程序代码。

如果(5)调用panic!会发生什么？根据IRC上的一些Rust开发者，尝试在非Rust调用帧（如(3)）内部执行panic!可能会产生未定义的行为。

但根据Rust文档，捕获 panic! 的唯一方法是使用 std::task::try，这会启动一个额外的线程。还有 rustrt::unwind::try，它不能在单个线程内嵌套两次，以及其他限制。

Benjamin Herr 提出一个解决方案，即在 (5) 中的代码发生 panic 时终止进程。当然，这并不完美，但终止比默默破坏内存并继续运行要好。因此，这个库使用了 abort。有没有更好的替代方案？

致谢与许可

这个代码的原始想法来自 Benjamin Herr。非常感谢！

此代码根据 Unlicense 的条款置于公共领域。