學習Rust最好的方法，就是和其他主流語言，比如Java、Python進行對比學習。不然怎么能get到它的特別呢？

1. 主流模式：try-catch-finally

基本上，當你學會了某種語言的try/catch，對這套機制的理解就能夠遷移到其他語言上了。除了C++沒有finally關鍵字外，像C#、Python、Java都有基本一致的異常處理邏輯：

• 用try塊包住可能會出現(xiàn)的異常；
• 用catch將之捕獲；
• finally塊統(tǒng)一處理資源的清理；

// Java ? try{ ? }catch(FileNotFoundException f){ ? }catch(IOException i){ ? }finally{ ? }

對于自定義的函數(shù)，我們可以throw異常。

// Javaimport java.io.*; public class ClassName {public void deposit(double amount) throws RemoteException{// Method implementationthrow new RemoteException();}//Remainder of class definition }

在這種異常處理系統(tǒng)中，對異常的定義是比較寬泛的：意料之外，情理之中。正是“異?！痹谡Z義上的模糊性，才產生了很多最佳實踐來指導異常的使用。從“正常到異常的程度”上，大致上可以歸為4類：

0 正常：不要用異常來進行流程控制，異常只用來處理“意外”。

這條教導告訴我們，如果分不清“異?！?#xff0c;那么至少在“正?！钡?、沒有意外的流程里，絕對不要用“異常機制來代替”。否則，代碼可讀性、可維護性將是災難。

1 人造語義異常：如果主流程中存在一個連續(xù)的“闖關”pipeline（一組按順序的調用，成功執(zhí)行才能執(zhí)行下一個，否則都算失敗），那么可以使用try塊來集中放置主流程代碼，catch塊來集中處理失敗情況，避免if-else箭頭形代碼。

try {getSomeThing_1();getSomeThing_2();getSomeThing_3(); catch(Exception e) {// deal with it }

這個技巧，和0 正常容易產生沖突，因為似乎有流程控制的嫌疑。但是凡事都有例外。這里的“意外”可以理解成一種語義上的“軟意外”——即不能出錯，區(qū)別于非法字符、找不到文件、連接不上等”硬意外“。

2 情理中的意外，可恢復。

前面提到的非法字符、找不到文件、連接不上，基本是公認的“意外”情況，基本都使用拋出異常的方式，但是這種情況，通常都會進行捕獲，并進行恢復。

3 無法意料的致命意外，不可恢復。

通常這種情況是，程序自身已經(jīng)沒有修復的空間，程序會中止：

• Bug：邏輯錯誤導致的溢出、除0；
• 致命錯誤：比如Java的JVM產生的Error；

2. Rust的Panic！

Rust里沒有異常。

但如果非要和異常機制進行映射，Rust可以說做的相當決絕、非黑即白。

0 正常，以返回值的形式。

相當于壓縮了上一節(jié)中的0、1、2項。沒有什么情理中的意外，網(wǎng)絡連不上、文件找不到、非法輸入，統(tǒng)統(tǒng)都用返回值的方式。

1 致命錯誤，不可恢復，非崩不可。

一旦存在不可恢復的錯誤，Rust使用Panic！宏來終止程序（線程）。一旦Panic！宏出手，基本沒得救（panic::catch_unwind是個例外，稍后說）。執(zhí)行時默認會進行stack unwind（棧反解），一層層上去，直到線程的頂端。

有些情況Panic！是你的程序所依賴的庫產生的，比如數(shù)組越界訪問時的實現(xiàn)。

另一種情況，是你自己的程序邏輯判斷產生了不可恢復的錯誤，可以手動觸發(fā)Panic！宏來終止程序。Panic！的使用與throw很類似。

我寫了一個小例子：打開一個文本文件，在寫入之前，把它刪掉，不僅沒有收到Panic！，返回值錯誤也沒有，居然寫成功了?？磥?#xff0c;這在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(b"Hello, world!")?;print!("Result is {:?} n", r); ?drop(f); ?Ok(()) }

輸出如下：

看File結構，同一個句柄handle，但是path前后卻發(fā)生了變化，文件都進回收站了，照樣寫你！

3. Rust的返回值Result

前面提到了，對于可恢復的錯誤，Rust一律使用返回值來進行檢查，而且提倡采用內置枚舉Result，還在實踐層面給了一定的約束：對于返回值為Result類型的函數(shù)，調用方如果沒有進行接收，編譯期會產生警告。很多庫函數(shù)都通過Result來告知調用方執(zhí)行結果，讓調用方來決定是否嚴重到了使用Panic！的程度。

Result枚舉的泛型定義如下：

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

在Rust標準庫中，可以找到許多以Result命名的類型，它們通常是Result泛型的特定版本，比如File::open的返回值就是把T替換成了std::fs::File，把E替換成了std::io::Error。

枚舉可以攜帶某個類型的數(shù)據(jù)，是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機制的實現(xiàn)，而是當Rust和其他編程語言互動時，避免其他語言代碼塊throw出異常。所以呢，錯誤處理的正道還是用Result。

從catch_unwind的名字上，需要留意下unwind這個限定詞，它意味著只有默認進行棧反解的panic可以被捕獲到，如果是設為直接終止程序的panic，就逮不住了。

細節(jié)可進一步參考Rust Documentation。

總結

以上是生活随笔為你收集整理的c# 溢出抛异常_Rust竟然没有异常处理？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。