广西建工集团冶金建设公司的网站,域名排名查询,备案 网站名称什么用,软件开发工具03173课后题学习Rust最好的方法#xff0c;就是和其他主流语言#xff0c;比如Java、Python进行对比学习。不然怎么能get到它的特别呢#xff1f;1. 主流模式#xff1a;try-catch-finally基本上#xff0c;当你学会了某种语言的try/catch#xff0c;对这套机制的理解就能够迁移到其…学习Rust最好的方法就是和其他主流语言比如Java、Python进行对比学习。不然怎么能get到它的特别呢1. 主流模式try-catch-finally基本上当你学会了某种语言的try/catch对这套机制的理解就能够迁移到其他语言上了。除了C没有finally关键字外像C#、Python、Java都有基本一致的异常处理逻辑用try块包住可能会出现的异常用catch将之捕获finally块统一处理资源的清理// Java
try{
}catch(FileNotFoundException f){
}catch(IOException i){
}finally{
}对于自定义的函数我们可以throw异常。// Javaimport java.io.*;
public class ClassName
{public void deposit(double amount) throws RemoteException{// Method implementationthrow new RemoteException();}//Remainder of class definition
}在这种异常处理系统中对异常的定义是比较宽泛的意料之外情理之中。正是“异常”在语义上的模糊性才产生了很多最佳实践来指导异常的使用。从“正常到异常的程度”上大致上可以归为4类0 正常不要用异常来进行流程控制异常只用来处理“意外”。这条教导告诉我们如果分不清“异常”那么至少在“正常”的、没有意外的流程里绝对不要用“异常机制来代替”。否则代码可读性、可维护性将是灾难。1 人造语义异常如果主流程中存在一个连续的“闯关”pipeline一组按顺序的调用成功执行才能执行下一个否则都算失败那么可以使用try块来集中放置主流程代码catch块来集中处理失败情况避免if-else箭头形代码。try {getSomeThing_1();getSomeThing_2();getSomeThing_3();
catch(Exception e) {// deal with it
}这个技巧和0 正常容易产生冲突因为似乎有流程控制的嫌疑。但是凡事都有例外。这里的“意外”可以理解成一种语义上的“软意外”——即不能出错区别于非法字符、找不到文件、连接不上等”硬意外“。2 情理中的意外可恢复。前面提到的非法字符、找不到文件、连接不上基本是公认的“意外”情况基本都使用抛出异常的方式但是这种情况通常都会进行捕获并进行恢复。3 无法意料的致命意外不可恢复。通常这种情况是程序自身已经没有修复的空间程序会中止Bug逻辑错误导致的溢出、除0致命错误比如Java的JVM产生的Error2. Rust的PanicRust里没有异常。但如果非要和异常机制进行映射Rust可以说做的相当决绝、非黑即白。0 正常以返回值的形式。相当于压缩了上一节中的0、1、2项。没有什么情理中的意外网络连不上、文件找不到、非法输入统统都用返回值的方式。1 致命错误不可恢复非崩不可。一旦存在不可恢复的错误Rust使用Panic宏来终止程序线程。一旦Panic宏出手基本没得救panic::catch_unwind是个例外稍后说。执行时默认会进行stack unwind栈反解一层层上去直到线程的顶端。有些情况Panic是你的程序所依赖的库产生的比如数组越界访问时的实现。另一种情况是你自己的程序逻辑判断产生了不可恢复的错误可以手动触发Panic宏来终止程序。Panic的使用与throw很类似。我写了一个小例子打开一个文本文件在写入之前把它删掉不仅没有收到Panic返回值错误也没有居然写成功了。看来这在Rust都不算事儿。着实让我惊讶了一小会儿。use std::io::prelude::*;
use std::thread;
use std::time;
use std::fs::OpenOptions;
fn main() - std::io::Result() {let mut f OpenOptions::new().write(true).open(hello.txt)?;print!({:?} n, f);
// on the moment, manually remove the file hello.txtlet ten_millis time::Duration::from_millis(10000);thread::sleep(ten_millis);
print!({:?} n, f);let r f.write_all(bHello, world!)?;print!(Result is {:?} n, r);
drop(f);
Ok(())
}
输出如下看File结构同一个句柄handle但是path前后却发生了变化文件都进回收站了照样写你3. Rust的返回值Result前面提到了对于可恢复的错误Rust一律使用返回值来进行检查而且提倡采用内置枚举Result还在实践层面给了一定的约束对于返回值为Result类型的函数调用方如果没有进行接收编译期会产生警告。很多库函数都通过Result来告知调用方执行结果让调用方来决定是否严重到了使用Panic的程度。Result枚举的泛型定义如下enum ResultT, E{Ok(T),Err(E),
}
在Rust标准库中可以找到许多以Result命名的类型它们通常是Result泛型的特定版本比如File::open的返回值就是把T替换成了std::fs::File把E替换成了std::io::Error。枚举可以携带某个类型的数据是Rust非常与众不同的特性。在上面的例子中可能会有个疑问并没有看到对Result的检查仔细看下机关就在于最后的那个?let mut f OpenOptions::new().write(true).open(hello.txt)?;
或许是Rust对于“需要大量的返回值检查”的介意于是有了“?”快捷运算符。它可以避免模板代码。上面1行顶下面4行let f OpenOptions::new().write(true).open(hello.txt);
let mut f match f{Ok(file) file,Err(e) return Err(e),
};
4. panic::catch_unwind最后再来说个例外panic::catch_unwind。先看下它的用法use std::panic;
let result panic::catch_unwind(|| {println!(hello!);
});
assert!(result.is_ok());
let result panic::catch_unwind(|| {panic!(oh no!);
});
assert!(result.is_err());
没错它的行为几乎就是try/catch了panic宏被捕获了程序并也没有挂返回了Err。尽管如此Rust的目的并不是让它成为try/catch机制的实现而是当Rust和其他编程语言互动时避免其他语言代码块throw出异常。所以呢错误处理的正道还是用Result。从catch_unwind的名字上需要留意下unwind这个限定词它意味着只有默认进行栈反解的panic可以被捕获到如果是设为直接终止程序的panic就逮不住了。细节可进一步参考Rust Documentation。
