写了几天 Rust 之后，不光被它的 Ownership, Lifetime 折磨的死去活来，还碰上个奇怪的错误处理方式。如果让程序员在 Java, C/C++, Python, Ruby, Scala, Go，甚至是 Lisp 语言之间换着学，那还都不是难事，但是拉个人去弄 Rust 就要命了。
有垃圾回收的语言基本就是想怎么写都成，程序运行时也不会出太大的事; 像 C/C++ 自己管理内存的语言写出来的程序通过编译也容易，只是执行时会有内存泄漏或地址越界。而选择号称性能与安全兼备的 Rust 语言的话，按照正常思维逻辑写出来的代码能通过编译就是最幸福的事。碰到关于 Ownership, Lifetime 之类的编译问题基本当前的 AI 也无解。
所以现在还能快乐的用 Java, Python 写代码的时光应该好好的去珍惜。
就算能侥幸的应付 Ownership, Lifetime 的问题，Rust 错误处理方式也会让人抓狂，起初大量的用 unwrap() 忽略错误，用多了也会觉得不是一回事。
主流的语言都是采纳 try/catch 方式处理异常方式，异常在栈中向上传播，想在哪一层捕获异常都行，所以才可能在某处集中的处理异常，也让程序结果返回与异常处理得已分离。
本人先前就对 Playframework 的 F.Either 可返回结果或错误的处理方式颇有微辞，而 Rust 彻底完全采用了 Result<Value, Error> 方式。Rust 有关异常方面只提供 panic! 宏来立即退出程序，像是 Java 异常抛到 main 函数而未处理一样。这方面 Go 有些类似，也是没有 try/catch, 异常处理方面有 panic, recover 和 differ。
大抵像 Go 和 Rust 恰恰就是对返回结果和异常处理分离有所不悦，才创建出用 Result<Value, Error> 让结果和错误走同一个出口，像是单孔目的鸟类，蛋和屎尿从一个口排出，每次接住的时候可能是要的蛋，但也可能是排泄物，虽获取到后自己分离。而 try/catch 的方式可以只获得蛋，有或没有，对于排泄物可以完全不管。
用 Result<Value, Error> 的方式需要每个方法都返回类似的数据类型，如果是不能的 Error 类型之间还需转换或保持兼容。比如说我们不得不写出下面那样的方法返回值
|
1 2 3 4 5 |
fn read_file(path: &str) -> std::io::Result<String> fn read_file1(path: &str) -> result::Result<String, Error> fn call_library() -> Result<(), Box<dyn std::error::Error>> |
上面 Result<String> 是 Result<String, Error> 的类型别名，如果像 std:error:Error 是一个 trait, 在编译器无法确定内存占用大小，所以不得不用 Box<dyn std::error:Error>> 的形式。
现在一步步来看 Rust 怎么处理错误的
Result<T, E> 是一个枚举
|
1 2 3 4 |
enum Result<T, E> { Ok(T), Err(E), } |
如果要从 Result 中得到值可以调用 unwrap() 方法
|
1 2 3 4 5 6 7 8 |
fn main() { let content = read_file("hello.txt").unwrap(); println!("file content: {}", content); } fn read_file(path: &str) -> std::io::Result<String> { fs::read_to_string(path) } |
如果此时读取的是一个不存在的文件，则会产生执行错误
thread 'main' (600254) panicked at src/main.rs:10:43:
calledResult::unwrap()on anErrvalue: Os { code: 2, kind: NotFound, message: "No such file or directory" }
unwrap() 失败则会产生一个 panic
基于此正确的做法通常是用 match 模式匹配分别处理 Ok 和 Err 中的情况
|
1 2 3 4 5 6 7 8 |
fn main() { let content = read_file("hellox.txt"); match read_file("hellox.txt") { Ok(content) => println!("file content: {}", content), Err(e) => eprintln!("Error reading file: {}", e), } } |
现在的错误信息是
Error reading file: No such file or directory (os error 2)
我们看到有些地方用 ? 替换 unwrap() 调用，下面的 main() 方法是不行的
|
1 2 3 4 |
fn main() { let content = read_file("hellox.txt")?; println!("file content: {}", content); } |
问题处理显示
^ cannot use the
?operator in a function that returns()
因为 main() 的返回值是 (), 修改 main() 的返回值类型为 std::io::Result<()>) 或 result::Result<(), io::Error>
|
1 2 3 4 5 |
fn main() -> result::Result<(), io::Error> { let content = read_file("hellox.txt")?; println!("file content: {}", content); Ok(()) } |
这样就可以用 ? 号了。这里 main() 函数返回值 Result<(), io::Error> 中的 Err 部分 io::Error 正好与 read_file() 返回值的 Err 部分类型一致所以才能用 ? 号。
如果修改 main() 的返回值为 result::Result<(), String> 就又不行了
|
1 2 3 4 5 |
fn main() -> result::Result<(), String> { let content = read_file("hellox.txt")?; println!("file content: {}", content); Ok(()) } |
? 处提示
^ the trait
From<std::io::Error>is not implemented forString
注意，Rust 并没有像支持异常的语言那样严格的错误必须实现了某个基类的类型，而是可以为任何类型，像 C/C++ 那样任何类型皆可 raise。
如果调用方法的 Result 的 Err 与被调用方法返回的 Result Err 部分可兼容的话，就可以用 ?。
|
1 |
let content = read_file("hellox.txt")?; |
中问号的意思是如果没有错误，即可被 unwrap() 则 unwrap(), 否则立即返回与调用方法兼容的错误。代码相当于是
|
1 2 3 4 5 6 |
fn main() -> result::Result<(), io::Error> { match read_file("hello.txt") { Ok(content) => Ok(()), Err(e) => Err(e) } } |
如果一个方法调用多个方法时
|
1 2 3 4 5 6 |
fn main() -> result::Result<(), io::Error> { println!("{}", foo()?); println!("{}", bar()?); println!("{}", baz()?); Ok(()) } |
能用 ? 号的前提是每个方法返回 Result<T, E> Err 部分必须与 io::Error 兼容，兼容就意味着如果出错时 ? 处必须能自动转换成 io:Error。
比如我们写下面的代码
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
#[derive(Debug)] struct CustomError { } fn main() -> result::Result<(), CustomError> { println!("{}", read_file("aaa")?); Ok(()) } fn read_file(path: &str) -> result::Result<String, std::io::Error> { let content = fs::read_to_string(path)?; Ok(content) } |
显示 std::io::Error 无法自动转换成 CustomError, 所以在问号处编译出错
|
1 2 3 4 5 6 7 8 |
13 | fn main() -> result::Result<(), CustomError> { | ------------------------------- expected `CustomError` because of this 14 | println!("{}", read_file("aaa")?); | ----------------^ the trait `From<std::io::Error>` is not implemented for `CustomError` | | | this can't be annotated with `?` because it has type `Result<_, std::io::Error>` | note: `CustomError` needs to implement `From<std::io::Error>` |
这时候可以主动 match 来转换，或者让 CustomError 和 std::io::Error 变得兼容，注意看错误信息里给出了办法，即 note: CustomError needs to implement From<std::io::Error>
给 CustomError 加上实现
|
1 2 3 4 5 |
impl From<io::Error> for CustomError { fn from(_err: io::Error) -> Self { CustomError {} } } |
现在编译就没问题了。执行后输出为
Error: CustomError
如果想要获得得原 io::Error 的信息，可以这么实现
|
1 2 3 4 5 6 7 8 9 10 |
#[derive(Debug)] struct CustomError { error: io::Error } impl From<io::Error> for CustomError { fn from(_err: io::Error) -> Self { CustomError {error: _err} } } |
再次执行的输出就变成了
Error: CustomError { error: Os { code: 2, kind: NotFound, message: "No such file or directory" } }
避免使用 unwrap()
好像我们所有做的一切就是在避免使用 unwrap()，函数调用链中途的 unwrap() 操作相当于是在 Java 的某一级方法调用中，catch 异常，打印异常信息并就地终止了运行
|
1 2 3 4 5 6 |
try{ // do something } catch (Exception ex) { ex.printStackTrace(); System.exit(1); } |
这样在调用顶层不知道途中发生了什么，对于 Rust 也样，在方法调用链接尽可能的是向上返回 Result<T, E> 或是 ?, 而非 unwrap().
关于 try!, try_catch! 宏
起先在 Rust 也有一个 try! 宏，现标记为
|
1 2 3 |
#[deprecated(since = "1.39.0", note = "use the `?` operator instead")] #[doc(alias = "?")] macro_rules! r#try { |
但要写成 try! 还不行
|
1 2 3 4 |
fn main() -> Result<(), io::Error> { println!("{}", try!(read_file("aaa"))); Ok(()) } |
提示的错误是
|
1 2 3 4 5 6 7 8 |
error: use of deprecated `try` macro --> src/main.rs:21:20 | 21 | println!("{}", try!(read_file("aaa"))); | ^^^^^^^^^^^^^^^^^^^^^^ | = note: in the 2018 edition `try` is a reserved keyword, and the `try!()` macro is deprecated help: you can use the `?` operator instead |
因为在 Rust 2018 edition 中 try 是一个保留关键字，但换成 r#try! 就可以
|
1 2 3 4 |
fn main() -> Result<(), io::Error> { println!("{}", r#try!(read_file("aaa"))); Ok(()) } |
效果和 read_file("aaa")? 是一样的。
try_catch! 是由不怎么爱 Rust 原生错误处理方式而提供的第三方库，需要安装
cargo add rust-try-catch
看下如何使用
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
fn main() { try_catch! { try { println!("{}", tri!(read_file("aaa"))); } catch (exception => CustomError) { println!("Caught a CustomError: {:?}", exception); } catch (exception => io::Error) { println!("Caught an io::Error: {:?}", exception); } catch panic (panic_info) { println!("Caught a panic: {:?}", panic_info); } finally { println!("Execution completed."); } } } |
虽然看到熟悉的 try/catch 的味道，但是间杂着 Rust 中固有气味，反而散发出某种怪味。
上面执行的错误是
Caught an io::Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }
Execution completed.
try_catch! 可以捕获到直接的 panic!
|
1 2 3 4 5 6 7 8 9 |
fn main() { try_catch! { try { panic!("This is a panic for demonstration purposes."); } catch panic (panic_info) { println!("Caught a panic: {:?}", panic_info); } } } |
输出
Caught a panic: Any { .. }
最后不妨看一下 Result 的 unwrap() 的实现代码
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
imp<T, E> Result<T, E> { ...... pub fn unwrap(self) -> T where E: fmt::Debug, { match self { Ok(t) => t, Err(e) => unwrap_failed("called `Result::unwrap()` on an `Err` value", &e), } } ...... } fn unwrap_failed(msg: &str, error: &dyn fmt::Debug) -> ! { panic!("{msg}: {error:?}"); } |
unwrap() 就是一个 match 表达式，有结果则取结果，出错误后最终产生一个 panic!
参考：
本文链接 https://yanbin.blog/rust-weird-error-handling-syntax/, 来自 隔叶黄莺 Yanbin Blog
[版权声明] 
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 进行许可。