Rust错误处理

zy010101

发布于 2023-03-27 09:53:49

6750

发布于 2023-03-27 09:53:49

文章被收录于专栏：程序员

错误处理

Rust 中的错误主要分为两类：

可恢复错误，通常用于从系统全局角度来看可以接受的错误，例如处理用户的访问、操作等错误，这些错误只会影响某个用户自身的操作进程，而不会对系统的全局稳定性产生影响
不可恢复错误，刚好相反，该错误通常是全局性或者系统性的错误，例如数组越界访问，系统启动时发生了影响启动流程的错误等等，这些错误的影响往往对于系统来说是致命的

不可恢复错误

不可恢复错误通常是非常严重的，例如：程序一开始读取配置文件失败或者连接数据库失败，诸如此类导致程序运行发生致命错误的，可以使用不可恢复错误。在rust中，触发不可恢复错误使用panic即可。触发panic可以分为被动触发和主动调用两种方式。

被动触发

下面是一个被动触发panic的例子。

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

    v[99];
}

这段代码由于数组越界访问，导致被动触发了panic。错误信息如下所示：

thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 99', src/main.rs:4:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

backtrace 栈展开

可以注意到上面的note提示我们在run的时候使用RUST_BACKTRACE=1来进行栈回溯，它包含了函数调用的顺序。例如：

 RUST_BACKTRACE=1 cargo run

执行以后输出的错误如下所示：

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

最近调用的函数排在列表的最上方。因为咱们的 main 函数基本是最先调用的函数了，所以排在了倒数第二位，还有一个关注点，排在最顶部最后一个调用的函数是 rust_begin_unwind，该函数的目的就是进行栈展开，呈现这些列表信息给我们。

要获取到栈回溯信息，你还需要开启 debug 标志，该标志在使用 cargo run 或者 cargo build 时自动开启（这两个操作默认是 Debug 运行方式）。同时，栈展开信息在不同操作系统或者 Rust 版本上也有所不同。

panic 时的两种终止方式

当出现 panic! 时，程序提供了两种方式来处理终止流程：栈展开和直接终止。

其中，默认的方式就是栈展开，这意味着 Rust 会回溯栈上数据和函数调用，因此也意味着更多的善后工作，好处是可以给出充分的报错信息和栈调用信息，便于事后的问题复盘。直接终止，顾名思义，不清理数据就直接退出程序，善后工作交与操作系统来负责。

对于绝大多数用户，使用默认选择是最好的，但是当你关心最终编译出的二进制可执行文件大小时，那么可以尝试去使用直接终止的方式，例如下面的配置修改 Cargo.toml 文件，实现在 release 模式下遇到 panic 直接终止：

[profile.release]
panic = 'abort'

主动调用panic

在某些特殊场景中，开发者想要主动抛出一个异常。rust提供了panic!宏，它可以在你调用时，打印出一个错误信息，展开报错点往前的函数调用堆栈，最后退出程序。一定是不可恢复的错误，才调用 panic! 处理，你总不想系统仅仅因为用户随便传入一个非法参数就崩溃吧？所以，只有当你不知道该如何处理时，再去调用 panic!

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

运行后输出：

thread 'main' panicked at 'crash', src/main.rs:8:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

它告诉我们，main 函数所在的线程崩溃了，发生的代码位置是 src/main.rs 中的第 8 行第 5 个字符（去除该行前面的空字符）

线程 panic 后，程序是否会终止？

如果是 main 线程，则程序会终止，如果是其它子线程，该线程会终止，但是不会影响 main 线程。因此，尽量不要在 main 线程中做太多任务，将这些任务交由子线程去做，就算子线程 panic 也不会导致整个程序的结束。

Result枚举类型

它被定义为如下：

enum Result<T, E> {
    Ok(T),
    Err(E),
}

泛型参数 T 代表成功时存入的正确值的类型，存放方式是 Ok(T)，E 代表错误时存入的错误值，存放方式是 Err(E)。一个实际的例子如下：

#![allow(unused)]
use std::fs::File;

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

    let f = match f {
        Ok(file) => file,
        Err(error) => {
            panic!("Problem opening the file: {:?}", error)
        },
    };
}

代码很清晰，对打开文件后的 Result<T, E> 类型进行匹配取值，如果是成功，则将 Ok(file) 中存放的的文件句柄 file 赋值给 f，如果失败，则将 Err(error) 中存放的错误信息 error 使用 panic 抛出来，进而结束程序。

直接 panic 还是过于粗暴，因为实际上 IO 的错误有很多种，我们需要对部分错误进行特殊处理，而不是所有错误都直接崩溃：

#![allow(unused)]
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),
        },
    };
}

上面代码在匹配出 error 后，又对 error 进行了详细的匹配解析，最终结果：

如果是文件不存在错误 ErrorKind::NotFound，就创建文件，这里创建文件File::create 也是返回 Result，因此继续用 match 对其结果进行处理：创建成功，将新的文件句柄赋值给 f，如果失败，则 panic 剩下的错误，一律 panic.

unwrap 和 expect

它们的作用就是，如果返回成功，就将 Ok(T) 中的值取出来，如果失败，就直接 panic。例如：

use std::fs::File;

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

如果hello.txt不存在，则会导致panic；而expect会带上自定义的错误提示信息，相当于重载了错误打印的函数：

use std::fs::File;

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

如果hello.txt不存在，那么panic的时候expect会带上自定义的错误提示信息“Failed to open hello.txt”。

传播错误

rust提供了错误传递的方式，以满足不同的编程风格来处理错误。有的人喜欢原地处理，有的人则是需要将错误传递到上层调用处进行处理。rust提供了?来进行错误传播。例如：

#![allow(unused)]
fn main() {
use std::fs::File;
use std::io;
use std::io::Read;

fn read_username_from_file() -> Result<String, io::Error> {
    let mut f = File::open("hello.txt")?;
    let mut s = String::new();
    f.read_to_string(&mut s)?;
    Ok(s)
}

let res = read_username_from_file();
dbg!(&res);
}

我们在此处进行了错误传递，当前目录下不存在hello.txt是，?会把发生的错误传递到上层，也是就是调用read_username_from_file处，错误结果保存在res中。输出如下所示：

[src/main.rs:64] &res = Err(
    Os {
        code: 2,
        kind: NotFound,
        message: "No such file or directory",
    },
)

详细的显示了错误信息，包含错误码code，错误种类kind，错误消息message。?其实是一个宏。当使用 ? 运算符时，如果表达式的结果是一个错误值，那么整个函数将立即返回这个错误值，否则会将表达式的结果进行包装并继续执行函数。?的强大之处在于自动类型提升，例如:

fn main() {
fn open_file() -> Result<File, Box<dyn std::error::Error>> {
    let mut f = File::open("hello.txt")?;
    Ok(f)
}
let res = open_file();
dbg!(&res);
}

当前目录下没有hello.txt时，open会失败，此时发送的错误是std::io::Error 类型，但是 open_file 函数返回的错误类型是 std::error::Error 的特征对象。标准库中定义的 From 特征，该特征有一个方法 from，用于把一个类型转成另外一个类型，? 可以自动调用该方法，然后进行隐式类型转换。因此只要函数返回的错误 ReturnError 实现了 From<OtherError> 特征，那么 ? 就会自动把 OtherError 转换为 ReturnError。除此之外，?还可以实现链式调用。例如：

#![allow(unused)]
fn main() {
use std::fs::File;
use std::io;
use std::io::Read;

fn read_username_from_file() -> Result<String, io::Error> {
    let mut s = String::new();

    File::open("hello.txt")?.read_to_string(&mut s)?;

    Ok(s)
}
}

确实牛逼，这样就不用写一大堆代码来处理错误了。

?用于Option返回

? 不仅仅可以用于 Result 的传播，还能用于 Option 的传播。

fn main() {
fn last_char_of_first_line(text: &str) -> Option<char> {
    text.lines().next()?.chars().last()
}
let res = last_char_of_first_line("123");
dbg!(&res);
}

如果next返回的是None，那么执行结束，直接返回None，否则接着进行链式调用。

带返回值的 main 函数

在了解了 ? 的使用限制后，这段代码你很容易看出它无法编译：

use std::fs::File;

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

因为 ? 要求 Result<T, E> 形式的返回值，而 main 函数的返回是 ()，怎么办？实际上 Rust 还支持另外一种形式的 main 函数：

use std::error::Error;
use std::fs::File;

fn main() -> Result<(), Box<dyn Error>> {
    let f = File::open("hello.txt")?;

    Ok(())
}

这样就能使用 ? 提前返回了，同时我们又一次看到了Box<dyn Error> 特征对象，因为 std::error:Error 是 Rust 中抽象层次最高的错误，其它标准库中的错误都实现了该特征，因此我们可以用该特征对象代表一切错误，就算 main 函数中调用任何标准库函数发生错误，都可以通过 Box<dyn Error>这个特征对象进行返回.

本文参与腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。

原始发表：2023-03-26，如有侵权请联系 cloudcommunity@tencent.com 删除

rust