Rust 程序设计语言

使用 panic! 造成的不可恢复的错误

有时你的代码中会发生糟糕的事情，而你对此无能为力。 在这些情况下，Rust 提供了 panic! 宏。 实际上，有两种方法会导致 panic：执行会导致代码 panic 的操作（例如访问超出末尾的数组）或显式调用 panic! 宏。 在这两种情况下，我们都会在程序中引起 panic。 默认情况下，这些 panic 将打印失败消息、展开、清理堆栈并退出。 通过环境变量，你还可以让 Rust 在发生 panic 时显示调用堆栈，以便更轻松地跟踪 panic 的来源。

[profile.release]
panic = 'abort'

让我们尝试在一个简单的程序中调用 panic!

文件名：src/main.rs

fn main() {
    panic!("crash and burn");
}

当你运行该程序时，你会看到类似这样的内容

$ cargo run
   Compiling panic v0.1.0 (file:///projects/panic)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.25s
     Running `target/debug/panic`
thread 'main' panicked at src/main.rs:2:5:
crash and burn
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

对 panic! 的调用导致了最后两行中包含的错误消息。 第一行显示了我们的 panic 消息以及 panic 发生的源代码位置：src/main.rs:2:5 表示它是 src/main.rs 文件的第二行，第五个字符。

在这种情况下，指示的行是我们代码的一部分，如果我们转到该行，我们会看到 panic! 宏调用。 在其他情况下，panic! 调用可能位于我们代码调用的代码中，并且错误消息报告的文件名和行号将是其他人的代码中调用 panic! 宏的位置，而不是最终导致 panic! 调用的我们代码的行。

我们可以使用 panic! 调用来自的函数的 backtrace 来找出我们代码中导致问题的部分。 为了理解如何使用 panic! backtrace，让我们看另一个例子，看看当 panic! 调用来自库时会是什么样子，因为我们的代码中存在 bug，而不是我们的代码直接调用宏。 列表 9-1 中的一些代码尝试访问向量中超出有效索引范围的索引。

文件名：src/main.rs

fn main() {
    let v = vec![1, 2, 3];

    v[99];
}

列表 9-1：尝试访问向量末尾之外的元素，这将导致调用 panic!

在这里，我们尝试访问向量的第 100 个元素（索引为 99，因为索引从零开始），但该向量只有三个元素。 在这种情况下，Rust 将会 panic。 使用 [] 应该返回一个元素，但是如果你传递一个无效的索引，Rust 在这里无法返回任何正确的元素。

在 C 语言中，尝试读取超出数据结构末尾的内容是未定义行为。 你可能会得到内存中与该数据结构中该元素对应的位置的任何内容，即使该内存不属于该结构。 这被称为缓冲区溢出读取（buffer overread），如果攻击者能够以某种方式操纵索引以读取他们不应该被允许读取的数据，这些数据存储在数据结构之后，则可能导致安全漏洞。

为了保护你的程序免受此类漏洞的侵害，如果你尝试读取不存在索引处的元素，Rust 将停止执行并拒绝继续。 让我们尝试一下看看

$ cargo run
   Compiling panic v0.1.0 (file:///projects/panic)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.27s
     Running `target/debug/panic`
thread 'main' panicked at src/main.rs:4:6:
index out of bounds: the len is 3 but the index is 99
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

此错误指向我们的 main.rs 的第 4 行，我们在其中尝试访问 v 中向量的索引 99。

note: 行告诉我们，我们可以设置 RUST_BACKTRACE 环境变量来获取导致错误的具体原因的 backtrace。 backtrace 是为到达此点而调用的所有函数的列表。 Rust 中的 backtrace 与在其他语言中的工作方式相同：读取 backtrace 的关键是从顶部开始读取，直到看到你编写的文件。 那就是问题起源的地方。 该位置上方的行是你的代码调用的代码； 下面的行是调用你的代码的代码。 这些之前和之后的行可能包括核心 Rust 代码、标准库代码或你正在使用的 crate。 让我们尝试通过将 RUST_BACKTRACE 环境变量设置为除 0 之外的任何值来获取 backtrace。 列表 9-2 显示了类似于你将看到的输出。

$ RUST_BACKTRACE=1 cargo run
thread 'main' panicked at src/main.rs:4:6:
index out of bounds: the len is 3 but the index is 99
stack backtrace:
   0: rust_begin_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
   2: core::panicking::panic_bounds_check
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:208:5
   3: <usize as core::slice::index::SliceIndex<[T]>>::index
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/slice/index.rs:255:10
   4: core::slice::index::<impl core::ops::index::Index<I> for [T]>::index
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/slice/index.rs:18:9
   5: <alloc::vec::Vec<T,A> as core::ops::index::Index<I>>::index
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/alloc/src/vec/mod.rs:2770:9
   6: panic::main
             at ./src/main.rs:4:6
   7: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

列表 9-2：当环境变量 RUST_BACKTRACE 设置时显示的对 panic! 的调用生成的 backtrace

输出很多！ 你看到的具体输出可能因你的操作系统和 Rust 版本而异。 为了获得包含此信息的 backtrace，必须启用调试符号。 默认情况下，当使用不带 --release 标志的 cargo build 或 cargo run 时，调试符号处于启用状态，就像我们在这里所做的那样。

在列表 9-2 的输出中，backtrace 的第 6 行指向我们项目中导致问题的行：src/main.rs 的第 4 行。 如果我们不希望我们的程序 panic，我们应该从指向我们编写的文件的第一行的位置开始调查。 在列表 9-1 中，我们故意编写了会导致 panic 的代码，修复 panic 的方法是不请求超出向量索引范围的元素。 当你的代码将来 panic 时，你需要弄清楚代码正在使用什么值执行什么操作来导致 panic，以及代码应该改为做什么。

我们将在本章后面的 “何时 panic! 与不 panic!”节中回到 panic! 以及我们应该和不应该使用 panic! 来处理错误情况的时机。 接下来，我们将看看如何使用 Result 从错误中恢复。