错误处理

当出现 panic 时，程序默认会开始 展开 ，这意味着 Rust 会 回溯栈 并清理它遇到的每一个函数的数据，不过这个回溯并清理的过程有很多工作

另一种选择是直接 终止 ，这会不清理数据就退出程序。那么程序所使用的内存需要由操作系统来清理

     如果需要项目的最终二进制文件越小越好，panic 时通过在 Cargo.toml 的 [profile] 部分增加 panic = 'abort'，可以由展开切换为终止

例如，如果想要在release模式中 panic 时直接终止：

[profile.release]
panic = 'abort'

在一个简单的程序中调用 panic!：

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

运行程序将会出现类似这样的输出：

$ cargo run
   Compiling panic v0.1.0 (/mnt/c/Users/I514692/AppData/Roaming/Documents/programming/html/klose911.github.io/src/rust/src/error_handle/panic)
    Finished dev [unoptimized + debuginfo] target(s) in 2.39s
     Running `target/debug/panic`
thread 'main' panicked at 'crash and burn', src/main.rs:2:5
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 来寻找代码中出问题的地方

看看另一个因为我们代码中的 bug 引起的别的库中 panic! 的例子，而不是直接的宏调用。下面是一个尝试通过索引访问 vector 中元素的例子：

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

    v[99];
}

报错信息如下：

thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 99', /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libcore/slice/mod.rs:2796:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

     这指向了一个不是自己编写的文件，libcore/slice/mod.rs。其为 Rust 源码中 slice 的实现

     这是当对 vector v 使用 [] 时 libcore/slice/mod.rs 中会执行的代码，也是真正出现 panic! 的地方

接下来的几行提醒我们可以设置 RUST_BACKTRACE 环境变量来得到一个 backtrace： 这是一个执行到目前位置所有被调用的函数的列表

Rust 的 backtrace 跟其他语言中的一样：

阅读 backtrace 的关键是从头开始读直到发现你编写的文件。这就是问题的发源地

这一行往上是你的代码所调用的代码；往下则是调用你的代码的代码

这些行可能包含核心 Rust 代码，标准库代码或用到的 crate 代码

将 RUST_BACKTRACE 环境变量设置为任何不是 0 的值来获取 backtrace 看看：

$ RUST_BACKTRACE=1 cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/panic`
thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 99', libcore/slice/mod.rs:2448:10
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
             at libstd/panicking.rs:476
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: std::panicking::try::do_call
             at libstd/panicking.rs:325
   7: core::ptr::drop_in_place
             at libcore/panicking.rs:77
   8: core::ptr::drop_in_place
             at libcore/panicking.rs:59
   9: <usize as core::slice::SliceIndex<[T]>>::index
             at libcore/slice/mod.rs:2448
  10: core::slice::<impl core::ops::index::Index<I> for [T]>::index
             at libcore/slice/mod.rs:2316
  11: <alloc::vec::Vec<T> as core::ops::index::Index<I>>::index
             at liballoc/vec.rs:1653
  12: panic::main
             at src/main.rs:4
  13: std::rt::lang_start::{{closure}}
             at libstd/rt.rs:74
  14: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  15: macho_symbol_search
             at libpanic_unwind/lib.rs:102
  16: std::alloc::default_alloc_error_hook
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  17: std::rt::lang_start
             at libstd/rt.rs:74
  18: panic::main

这里有大量的输出：

• 实际看到的输出可能因 不同的操作系统 和 Rust 版本 而有所不同
• 为了获取带有这些信息的 backtrace，必须 启用 debug 标识
  • 当 不使用 –release 参数运行 cargo build 或 cargo run 时 debug 标识会默认启用，就像这里一样

     输出中，backtrace 的 12 行指向了我们项目中造成问题的行：src/main.rs 的第 4 行

     如果你不希望程序 panic，第一个提到我们编写的代码行的位置是你应该开始调查的，以便查明是什么值如何在这个地方引起了 panic

     在示例中，我们故意编写会 panic 的代码来演示如何使用 backtrace，修复这个 panic 的方法就是不要尝试在一个只包含三个项的 vector 中请求索引是 100 的元素

     当将来你的代码出现了 panic，你需要搞清楚在这特定的场景下代码中执行了什么操作和什么值导致了 panic，以及应当如何处理才能避免这个问题

     上面的代码不管 File ::open 是因为什么原因失败都会 panic!

     真正希望的是对不同的错误原因采取不同的行为：
     如果 File ::open因为文件不存在而失败，希望创建这个文件并返回新文件的句柄

     如果 File ::open 因为任何其他原因失败，例如没有打开文件的权限，仍然希望像示例那样 panic!

为 match 增加了另一个分支：

use std::fs::File;
use std::io::ErrorKind;

fn main() {
    let f = File ::open("hello.txt");

    let f = match f {
        Ok(file) => file,
        Err(error) => match error.kind() {
            ErrorKind::NotFound => match File ::create("hello.txt") {
                Ok(fc) => fc,
                Err(e) => panic!("Problem creating the file: {:?}", e),
            },
            other_error => panic!("Problem opening the file: {:?}", other_error),
        },
    };
}

File ::open 返回的 Err 成员中的值类型 io::Error ，它是一个标准库中提供的结构体：这个结构体有一个返回 io::ErrorKind 值的 kind 方法可供调用：

• io::ErrorKind 是一个标准库提供的枚举，它的成员对应 io 操作可能导致的不同错误类型：
  • 感兴趣的成员是 ErrorKind::NotFound ，它代表尝试 打开的文件并不存在

     希望在匹配守卫中检查的条件是 error.kind() 的返回值是 ErrorKind的 NotFound 成员

     如果是，则尝试通过 File ::create 创建文件
     然而因为 File ::create 也可能会失败，还需要增加一个内部 match 语句。当文件不能被打开，会打印出一个不同的错误信息

     外部 match 的最后一个分支保持不变，这样对任何除了文件不存在的错误会使程序 panic

然而这里有很多的嵌套的 match 操作符，Result<T, E> 有很多接受 闭包 的方法，并采用 match 表达式实现。一个更老练的 Rustacean 可能会这么写：

use std::fs::File;
use std::io::ErrorKind;

fn main() {
    let f = File ::open("hello.txt").unwrap_or_else(|error| {
        if error.kind() == ErrorKind::NotFound {
            File ::create("hello.txt").unwrap_or_else(|error| {
                panic!("Problem creating the file: {:?}", error);
            })
        } else {
            panic!("Problem opening the file: {:?}", error);
        }
    });
}

     虽然这段代码和开始一样的行为，但比大量的 match 表达式且更容易阅读

     在处理错误时，还有很多这类方法可以消除大量嵌套的 match 表达式

match 能够胜任它的工作，不过它可能有点冗长并且不总是能很好的表明其意图

Result<T, E> 类型定义了很多辅助方法来处理各种情况。其中之一叫做 unwrap ：

• 如果 Result 值是成员 Ok，unwrap 会返回 Ok 中的值
• 如果 Result 是成员 Err，unwrap 会调用 panic!

这里是一个实践 unwrap 的例子：

use std::fs::File;

fn main() {
    let f = File ::open("hello.txt").unwrap();
}

如果调用这段代码时不存在 hello.txt 文件，将会看到一个 unwrap 调用 panic! 时提供的错误信息：

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error {repr: Os { code: 2, message: "No such file or directory" } }',src/libcore/result.rs:906:4

另一个类似于 unwrap 的方法 expect ，它还允许选择 panic! 的错误信息 ：

use std::fs::File;

fn main() {
    let f = File ::open("hello.txt").expect("Failed to open hello.txt");
}

expect 与 unwrap 的使用方式一样：返回文件句柄或调用 panic! 宏。expect 用来调用 panic! 的错误信息将会作为参数传递给 expect ，而不像unwrap 那样使用默认的 panic! 信息。它看起来像这样：

thread 'main' panicked at 'Failed to open hello.txt: Error { repr: Os { code:2, message: "No such file or directory" } }', src/libcore/result.rs:906:4

     这个错误信息以指定的文本开始，Failed to open hello.txt，将会更容易找到代码中的错误信息来自何处

     如果在多处使用 unwrap，则需要花更多的时间来分析到底是哪一个 unwrap 造成了 panic，因为所有的 unwrap 调用都打印相同的信息

当编写一个实现会调用一些可能会失败的操作的函数时，除了在这个函数中处理错误外，还可以选择让 调用者知道这个错误 并 决定该如何处理 。这被称为 传播 错误

     这样能更好的控制代码调用，因为比起实现代码所拥有的上下文，调用者可能拥有更多信息或逻辑来决定应该如何处理错误

例如，下面的示例展示了一个从文件中读取用户名的函数。如果文件不存在或不能读取，这个函数会将这些错误返回给调用它的代码：

use std::io;
use std::io::Read;
use std::fs::File;

fn read_username_from_file() -> Result<String, io::Error> {
    let f = File ::open("hello.txt");

    let mut f = match f {
        Ok(file) => file,
        Err(e) => return Err(e),
    };

    let mut s = String::new();

    match f.read_to_string(&mut s) {
        Ok(_) => Ok(s),
        Err(e) => Err(e),
    }
}

这个函数的返回值： Result<String, io::Error> 。这意味着函数返回一个 Result<T, E> 类型的值，其中：

• T 的具体类型是 String：如果这个函数没有出任何错误成功返回，函数的调用者会收到一个包含“从文件中读取到用户名”的 Ok 值
• E 的具体类型是 io::Error：如果函数遇到任何错误，函数的调用者会收到一个 Err 值，它储存了一个包含更多这个问题相关信息的 io::Error 实例

     这里选择 io::Error 作为函数的返回值是因为它正好是函数体中那两个可能会失败的操作的错误返回值：File ::open 函数和 read_to_string 方法

函数体：

1. 以 File ::open 函数开头
2. 使用 match 处理返回值 Result
   • 当 Err 时不再调用 panic!，而是提早返回并将 File ::open 返回的错误值作为函数的错误返回值传递给调用者
   • 如果 File ::open 成功了，将文件句柄储存在变量 f 中并继续
3. 在变量 s 中创建了一个新 String
4. 调用文件句柄 f 的 read_to_string 方法来将文件的内容读取到 s 中，read_to_string 方法也返回一个 Result 因为它也可能会失败：需要另一个 match 来处理这个 Result：
   • 如果 read_to_string 成功了，那么这个函数就成功了，并返回文件中的用户名，它现在位于被封装进 Ok 的 s 中
   • 如果read_to_string 失败了，则像之前处理 File ::open 的返回值的 match 那样返回错误值
   • 并不需要显式的调用 return，因为这是函数的最后一个表达式

调用这个函数的代码最终会得到一个包含用户名的 Ok 值，或者一个包含 io::Error 的 Err 值

然而我们无从得知调用者会如何处理这些值。如果他们得到了一个 Err 值，他们可能会选择：
1. panic! 并使程序崩溃
2. 使用一个默认的用户名
3. 从文件之外的地方寻找用户名
，，，

我们没有足够的信息知晓调用者具体会如何尝试，所以将所有的成功或失败信息向上传播，让他们选择合适的处理方法

这种传播错误的模式在 Rust 是如此的常见，以至于 Rust 提供了 ? 问号运算符来使其更易于处理

当编写一个 示例 来展示一些概念时，在拥有健壮的错误处理代码的同时也会使得 例子不那么明确

     例如，调用一个类似 unwrap 这样可能 panic! 的方法可以被理解为一个你实际希望程序处理错误方式的占位符，它根据其余代码运行方式可能会各不相同

类似地，在准备好决定如何处理错误之前，unwrap和expect方法在 原型 设计时非常方便

   当准备好让程序更加健壮时，它们会在代码中留下清晰的标记

如果方法调用在 测试 中失败了，当然希望这个测试都失败，即便这个方法并不是需要测试的功能

   因为 panic! 是测试如何被标记为失败的，调用 unwrap 或 expect 就是应该发生的事情

当有一些其他的逻辑来确保 Result 会是 Ok 值时，调用 unwrap 也是合适的，虽然编译器无法理解这种逻辑。你仍然需要处理一个 Result 值：即使在你的特定情况下逻辑上是不可能的，你所调用的任何操作仍然有可能失败。如果通过人工检查代码来确保永远也不会出现 Err 值，那么调用 unwrap 也是完全可以接受的，这里是一个例子：

use std::net::IpAddr;

let home: IpAddr = "127.0.0.1".parse().unwrap();

     通过解析一个硬编码的字符来创建一个 IpAddr 实例

     可以看出 127.0.0.1 是一个有效的 IP 地址，所以这里使用 unwrap 是可以接受的

     然而，拥有一个硬编码的有效的字符串也不能改变 parse 方法的返回值类型：它仍然是一个 Result 值，而编译器仍然就好像还是有可能出现 Err 成员，那样要求我们处理 Result，因为编译器还没有智能到可以识别出这个字符串总是一个有效的 IP 地址

     如果 IP 地址字符串来源于用户而不是硬编码进程序中的话，那么就 确实 有失败的可能性，这时就绝对需要我们以一种更健壮的方式处理 Result 了

• 在当有可能会导致 有害状态 的情况下建议使用 panic!

     有害状态是指当一些 假设 、 保证 、 协议 或 不可变性 被打破的状态

     例如无效的值、自相矛盾的值或者被传递了不存在的值 

外加如下几种情况：

• 有害状态并不包含 预期 会偶尔发生的错误
• 之后的代码的运行 依赖 于处于这种有害状态
• 当没有可行的手段来将有害状态信息编码进所使用的类型中的情况
• 如果 别人调用你的代码并传递了一个没有意义的值 ，最好的情况也许就是 panic! 并警告使用你的库的人他的代码中有 bug 以便他能在开发时就修复它
• 类似的，panic! 通常适合调用 不能够控制的外部代码 时，这时无法修复其返回的无效状态

然而当错误预期会出现时，返回 Result 仍要比调用 panic! 更为合适

     这样的例子包括解析器接收到错误数据，或者 HTTP 请求返回一个表明触发了限流的状态

     在这些例子中，应该通过返回 Result 来表明失败预期是可能的，这样将有害状态向上传播，调用者就可以决定该如何处理这个问题

     使用 panic! 来处理这些情况就不是最好的选择

当代码对值进行操作时，应该首先验证值是有效的，并在其无效时 panic!

     这主要是出于安全的原因：尝试操作无效数据会暴露代码漏洞
     这就是标准库在尝试越界访问数组时会 panic! 的主要原因：尝试访问不属于当前数据结构的内存是一个常见的安全隐患

     函数通常都遵循契约：他们的行为只有在输入满足特定条件时才能得到保证。当违反契约时 panic 是有道理的
     因为这通常代表调用方的 bug，而且这也不是那种你希望调用方必须处理的错误
     事实上也没有合理的方式来恢复调用方的代码：调用方的 程序员 需要修复其代码
     函数的契约，尤其是当违反它会造成 panic 的契约，应该在函数的 API 文档中得到解释

然而在所有函数中都拥有许多错误检查是冗长而烦人的

幸运的是，可以利用 Rust 的类型系统（以及编译器的类型检查）为你进行很多检查

如果函数有一个特定类型的参数，可以在知晓编译器已经确保其拥有一个有效值的前提下进行你的代码逻辑。例如：
1. 如果你使用了一个不同于 Option 的类型，而且程序期望它是 有值 的并且不是 空值。你的代码无需处理 Some 和 None 这两种情况，它只会有一种情况就是绝对会有一个值，尝试向函数传递空值的代码甚至根本不能编译，所以你的函数在运行时没有必要判空
2. 使用像 u32 这样的无符号整型，也会确保它永远不为负

Rust 的错误处理功能被设计为帮助编写更加健壮的代码：

• panic! 宏代表一个程序无法处理的状态，并停止执行而不是使用无效或不正确的值继续处理
• Result 枚举代表操作可能会在一种可以恢复的情况下失败。可以使用 Result 来告诉代码调用者他需要处理潜在的成功或失败

在适当的场景使用 panic! 和 Result 将会使你的代码在面对不可避免的错误时显得更加可靠

Next：泛型

Previous：集合

Home: 目录