Rust处理错误的实现方法

错误处理

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>这个特征对象进行返回.

原文地址:https://blog.csdn.net/zy010101/article/details/129784427