要 panic! 还是不要 panic! - Rust 程序设计语言 - 《Rust 程序设计语言》中文版

要 `panic!` 还是不要 `panic!`

那么，你如何决定何时应该调用 panic!，何时应该返回 Result 呢？当代码 panic 时，没有办法恢复。你可以为任何错误情况调用 panic!，无论是否有可能恢复，但那样你就代表调用代码做出了情况不可恢复的决定。当你选择返回 Result 值时，你给调用代码提供了选择。调用代码可以选择尝试以适合其情况的方式恢复，或者它可以决定在这种情况下 Err 值是不可恢复的，因此它可以调用 panic! 并将你的可恢复错误变成不可恢复的错误。因此，当你定义一个可能失败的函数时，返回 Result 是一个好的默认选择。

在示例、原型代码和测试等情况下，编写 panic 而不是返回 Result 的代码更合适。让我们探讨一下原因，然后讨论编译器无法判断失败是不可能的情况，但作为人类你可以判断的情况。本章最后将给出关于如何在库代码中决定是否 panic 的一般指南。

示例、原型代码和测试

当你编写示例来阐述某些概念时，包含健壮的错误处理代码可能会使示例不太清晰。在示例中，人们理解对像 unwrap 这样可能 panic 的方法的调用，旨在作为应用程序处理错误方式的占位符，这可能会根据代码的其余部分而有所不同。

同样，在原型设计阶段，在你准备好决定如何处理错误之前，unwrap 和 expect 方法非常方便。它们在你的代码中留下清晰的标记，以便在你准备好让程序更健壮时使用。

如果测试中的方法调用失败，你希望整个测试失败，即使该方法不是正在测试的功能。因为 panic! 是测试标记为失败的方式，所以调用 unwrap 或 expect 正是应该发生的。

你比编译器拥有更多信息的情况

当你有一些其他逻辑可以确保 Result 将具有 Ok 值，但该逻辑不是编译器能够理解的时，调用 unwrap 或 expect 也是合适的。你仍然需要处理一个 Result 值：无论你调用的操作是什么，通常都可能失败，即使在你的特定情况下逻辑上是不可能的。如果你可以通过手动检查代码来确保永远不会有 Err 变体，那么调用 unwrap 是完全可以接受的，甚至更好的是在 expect 文本中记录你认为永远不会有 Err 变体的原因。这是一个例子

fn main() {
    use std::net::IpAddr;

    let home: IpAddr = "127.0.0.1"
        .parse()
        .expect("Hardcoded IP address should be valid");
}

我们正在通过解析硬编码的字符串来创建一个 IpAddr 实例。我们可以看到 127.0.0.1 是一个有效的 IP 地址，因此在这里使用 expect 是可以接受的。但是，拥有硬编码的有效字符串不会更改 parse 方法的返回类型：我们仍然得到一个 Result 值，并且编译器仍然会让我们处理 Result，就好像 Err 变体是一种可能性一样，因为编译器不够智能，无法看到这个字符串始终是一个有效的 IP 地址。如果 IP 地址字符串来自用户而不是硬编码到程序中，因此 *确实* 有失败的可能性，我们肯定希望以更健壮的方式处理 Result。提及此 IP 地址是硬编码的假设将促使我们将 expect 更改为更好的错误处理代码，如果在将来我们需要从其他来源获取 IP 地址。

错误处理指南

当你的代码有可能最终进入不良状态时，建议让你的代码 panic。在这种情况下，*不良状态* 是指某些假设、保证、合同或不变性已被破坏，例如当无效值、矛盾值或缺失值传递给你的代码时——加上以下一个或多个条件

不良状态是意外发生的事情，而不是可能偶尔发生的事情，例如用户输入格式错误的数据。
此后的代码需要依赖于不处于这种不良状态，而不是在每一步都检查问题。
没有好的方法在您使用的类型中编码此信息。我们将在 “将状态和行为编码为类型”第 18 章的章节中，通过一个例子来说明我们的意思。

如果有人调用你的代码并传入没有意义的值，最好在可能的情况下返回错误，以便库的用户可以决定在这种情况下他们想做什么。但是，在继续操作可能不安全或有害的情况下，最好的选择可能是调用 panic! 并提醒使用你的库的人员他们代码中的错误，以便他们可以在开发期间修复它。同样，如果你调用不受你控制的外部代码，并且它返回你无法修复的无效状态，那么 panic! 通常也是合适的。

但是，当预期会发生失败时，返回 Result 比调用 panic! 更合适。例如，解析器收到格式错误的数据，或者 HTTP 请求返回指示你已达到速率限制的状态。在这些情况下，返回 Result 表明失败是一种预期的可能性，调用代码必须决定如何处理。

当你的代码执行的操作如果使用无效值调用可能会使用户面临风险时，你的代码应首先验证值是否有效，如果值无效则 panic。这主要是出于安全原因：尝试对无效数据进行操作可能会使你的代码暴露于漏洞。这是标准库在您尝试越界内存访问时调用 panic! 的主要原因：尝试访问不属于当前数据结构的内存是一个常见的安全问题。函数通常具有*合同*：只有当输入满足特定要求时，才能保证它们的行为。当合同被违反时 panic 是有道理的，因为合同违规始终表明调用方存在错误，这不是您希望调用代码显式处理的那种错误。实际上，调用代码没有合理的恢复方法；调用*程序员*需要修复代码。函数的合同，尤其是当违规会导致 panic 时，应在函数的 API 文档中进行说明。

但是，在所有函数中进行大量错误检查会显得冗长且令人厌烦。幸运的是，你可以使用 Rust 的类型系统（以及编译器完成的类型检查）为你完成许多检查。如果你的函数具有特定类型作为参数，则可以继续执行代码的逻辑，因为你知道编译器已经确保你具有有效值。例如，如果你使用类型而不是 Option，则你的程序期望拥有*某些东西*而不是*什么都没有*。然后，你的代码不必处理 Some 和 None 变体的两种情况：它只会有一种情况，即肯定有一个值。尝试将空值传递给你的函数的代码甚至无法编译，因此你的函数不必在运行时检查这种情况。另一个示例是使用无符号整数类型（例如 u32），这确保参数永远不会为负数。

创建用于验证的自定义类型

让我们进一步深入探讨使用 Rust 的类型系统来确保我们拥有有效值的想法，并研究创建用于验证的自定义类型。回想一下第 2 章中的猜数字游戏，我们的代码要求用户猜一个介于 1 到 100 之间的数字。在将其与我们的秘密数字进行比较之前，我们从未验证用户的猜测是否在这些数字之间；我们只验证了猜测是正数。在这种情况下，后果不是很严重：我们的“太高”或“太低”的输出仍然是正确的。但是，引导用户进行有效猜测，并在用户猜测超出范围的数字与用户输入字母等情况时具有不同的行为，这将是一个有用的改进。

一种方法是将猜测解析为 i32 而不是仅解析为 u32 以允许潜在的负数，然后添加一个检查以确保数字在范围内，如下所示

文件名：src/main.rs

use rand::Rng;
use std::cmp::Ordering;
use std::io;

fn main() {
    println!("Guess the number!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    loop {
        // --snip--

        println!("Please input your guess.");

        let mut guess = String::new();

        io::stdin()
            .read_line(&mut guess)
            .expect("Failed to read line");

        let guess: i32 = match guess.trim().parse() {
            Ok(num) => num,
            Err(_) => continue,
        };

        if guess < 1 || guess > 100 {
            println!("The secret number will be between 1 and 100.");
            continue;
        }

        match guess.cmp(&secret_number) {
            // --snip--
            Ordering::Less => println!("Too small!"),
            Ordering::Greater => println!("Too big!"),
            Ordering::Equal => {
                println!("You win!");
                break;
            }
        }
    }
}

if 表达式检查我们的值是否超出范围，告诉用户问题，并调用 continue 以开始循环的下一次迭代并要求再次猜测。在 if 表达式之后，我们可以继续进行 guess 和秘密数字之间的比较，因为我们知道 guess 在 1 到 100 之间。

但是，这不是一个理想的解决方案：如果程序绝对关键只能对 1 到 100 之间的值进行操作，并且它有很多具有此要求的函数，那么在每个函数中都进行这样的检查将是乏味的（并且可能会影响性能）。

相反，我们可以创建一个新类型，并将验证放在一个函数中，以创建该类型的实例，而不是在到处重复验证。这样，函数可以安全地在其签名中使用新类型，并自信地使用它们接收的值。列表 9-13 展示了一种定义 Guess 类型的方法，该类型仅在 new 函数接收到介于 1 到 100 之间的值时才创建 Guess 的实例。

文件名：src/lib.rs

#![allow(unused)]
fn main() {
pub struct Guess {
    value: i32,
}

impl Guess {
    pub fn new(value: i32) -> Guess {
        if value < 1 || value > 100 {
            panic!("Guess value must be between 1 and 100, got {value}.");
        }

        Guess { value }
    }

    pub fn value(&self) -> i32 {
        self.value
    }
}
}

列表 9-13：一个 Guess 类型，它将仅继续处理介于 1 到 100 之间的值

首先，我们定义一个名为 Guess 的结构体，它有一个名为 value 的字段，该字段保存一个 i32。这是数字将要存储的地方。

然后，我们在 Guess 上实现一个名为 new 的关联函数，该函数创建 Guess 值的实例。new 函数定义为具有一个名为 value 的 i32 类型参数，并返回一个 Guess。new 函数体中的代码测试 value 以确保它在 1 到 100 之间。如果 value 未通过此测试，我们将进行 panic! 调用，这将提醒编写调用代码的程序员他们有一个需要修复的错误，因为创建一个 value 超出此范围的 Guess 将违反 Guess::new 所依赖的合同。Guess::new 可能 panic 的条件应在其面向公众的 API 文档中讨论；我们将在第 14 章中介绍在您创建的 API 文档中指示 panic! 可能性的文档约定。如果 value 通过测试，我们将创建一个新的 Guess，其 value 字段设置为 value 参数，并返回 Guess。

接下来，我们实现一个名为 value 的方法，该方法借用 self，没有其他参数，并返回一个 i32。这种方法有时被称为 *getter*，因为它的目的是从其字段获取一些数据并返回它。此公共方法是必需的，因为 Guess 结构体的 value 字段是私有的。重要的是 value 字段是私有的，这样使用 Guess 结构体的代码不允许直接设置 value：模块外部的代码 *必须* 使用 Guess::new 函数来创建 Guess 的实例，从而确保 Guess 不可能具有未经 Guess::new 函数中的条件检查的 value。

一个具有参数或仅返回 1 到 100 之间数字的函数，然后可以在其签名中声明它接受或返回 Guess 而不是 i32，并且不需要在其主体中进行任何额外的检查。

总结

Rust 的错误处理功能旨在帮助你编写更健壮的代码。panic! 宏发出信号，表明你的程序处于无法处理的状态，并让你告诉进程停止，而不是尝试使用无效或不正确的值继续运行。Result 枚举使用 Rust 的类型系统来指示操作可能会以你的代码可以从中恢复的方式失败。你可以使用 Result 来告知调用你的代码的代码，它也需要处理潜在的成功或失败。在适当的情况下使用 panic! 和 Result 将使你的代码在面对不可避免的问题时更加可靠。

现在你已经看到了标准库如何使用泛型与 Option 和 Result 枚举的有用方法，我们将讨论泛型的工作原理以及如何在你的代码中使用它们。