本文主要是介绍改进rust代码的35种具体方法-类型(十八)-不要惊慌,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
上一篇文章
它看起来非常复杂,这就是为什么它贴合的塑料盖上用大号友好字母印上“不要恐慌”的原因之一。——道格拉斯·亚当斯
此项目的标题将更准确地描述为更喜欢返回Result
而不是使用panic!
(但不要惊慌更吸引人)。
Rust的panic机制主要是为程序中不可恢复的错误而设计的,默认情况下它会终止发出panic的线程。然而,这个默认值还有其他替代方案。
特别是,来自具有异常系统(如Java或C++)的语言的Rust新手有时会扑向std::panic::catch_unwind作为模拟异常的一种方式,因为它似乎提供了一种在呼叫堆栈更远的点捕获恐慌的机制。
fn divide(a: i64, b: i64) -> i64 {if b == 0 {panic!("Cowardly refusing to divide by zero!");}a / b
}
尝试用无效输入调用此内容,按预期失败:
// Attempt to discover what 0/0 is...
let result = divide(0, 0);
thread 'main' panicked at 'Cowardly refusing to divide by zero!', main.rs:11:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
使用catch_unwind
捕捉恐慌的包装器:
fn divide_recover(a: i64, b: i64, default: i64) -> i64 {let result = std::panic::catch_unwind(|| divide(a, b));match result {Ok(x) => x,Err(_) => default,}
}
似乎工作并模拟catch
:
let result = divide_recover(0, 0, 42);
println!("result = {result}");
result = 42
然而,外表可能是欺骗性的。这种方法的第一个问题是,恐慌并不总是解除;有一个编译器选项(也可以通过Cargo.toml配置文件设置访问),可以转移恐慌行为,以便立即中止该过程:
thread 'main' panicked at 'Cowardly refusing to divide by zero!', main.rs:11:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
/bin/sh: line 1: 29100 Abort trap: 6 cargo run --release
这使得任何模拟异常的尝试完全受制于更广泛的项目设置。同样,一些目标平台(例如WebAssembly)总是在恐慌时中止,无论任何编译器或项目设置如何。
恐慌处理暴露的一个更微妙的问题是异常安全:如果恐慌发生在数据结构操作的中途,它会消除数据结构处于自洽状态的任何保证。众所周知,自20世纪90年代以来,在存在异常的情况下保留内部不变量是非常困难的;1这是谷歌(著名的)禁止在其C++代码中使用异常的主要原因之一。
最后,恐慌传播也与FFI(外部函数接口)边界的相互作用很差;使用catch_unwind
防止Rust代码中的恐慌跨越FFI边界传播到非Rust调用代码。
那么,除了恐慌,还有什么办法呢?处理错误条件?对于库代码,最好的替代方法是通过返回带有适当错误类型(Item 4)的Result,使错误成为其他人的问题。这允许库用户自己决定下一步要做什么——这可能涉及将问题传递给行中的下一个调用者,通过?操作符。
责任总有止点,一个有用的经验法则是,恐慌是可以的!(或者unwrap(), expect()等),如果你控制了main;在这一点上,没有进一步的调用者可以将责任传递给。
又一个明智的恐慌!即使在库代码中,在很少遇到错误的情况下也是如此,并且您不希望用户不得不使用.unwrap()调用来丢弃他们的代码。
如果错误情况只是因为(例如)内部数据损坏,而不是由于无效的输入,那么就会引发panic!
是合法的。
允许由无效输入触发的恐慌,但此类无效输入不同寻常,这甚至偶尔也是有用的。当相关切入点成对出现时,这效果最佳:
- 一个“无懈可犯”的版本,其签名意味着它总是成功的(如果它不能成功,就会惊慌失措)
- 一个“易失”版本,返回一个
Result
对于前者,Rust的API指南表明panic!
应在内联文档的特定部分中记录。
标准库中的String::from_utf8_unchecked和String::from_utf8入口点是后者的一个例子(尽管在这种情况下,恐慌实际上被推迟到使用由无效输入构造的aString)。
假设您试图遵守本项目中的建议,有几件事需要记住。首先,恐慌可以以不同的形式出现;避免panic!
还涉及避免以下内容:
更难发现的是以下东西:
slice[index]
当指数不在范围之内时x / y
当y
为零时
关于避免恐慌的第二个观察是,一个涉及人类持续警惕的计划从来都不是一个好主意。
然而,对机器的持续警惕是另一回事:在您的持续集成系统中添加检查,以发现新的、可能恐慌的代码要可靠得多。一个简单的版本可能是最常见的恐慌进入点的简单grep(如前所示);更彻底的检查可能涉及来自Rust生态系统的额外工具,例如设置一个构建变体来拉入no_panic板条箱。
1 Tom Cargill1994年在C++报告中的文章探讨了C++模板代码的异常安全有多困难,Herb Sutter的本周大师#8专栏也是如此。
下一篇文章-避免使用反射https://blog.csdn.net/qq_34841911/article/details/139180459
这篇关于改进rust代码的35种具体方法-类型(十八)-不要惊慌的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!