各種編程語言中的「錯誤/異常處理」有哪些成熟的，優雅的或是熱門的機制/思想？

fn and_then&(self, f: F) -&> Option&
where F: FnOnce(T) -&> Option&
{
match self{
Some(x) =&> f(x),
None =&> None,
}
}


（文檔在這裡：std::option::Option）

enum Result&{ // data Either t e =
Ok(T), // Left t |
Err(E) // Right e
}


至少Ok和Err比Left和Right高到不知哪裡去了

use std::io;

let mut s=String::new();
io::stdin().read_line(mut s).ok();


read_line()的作用是往s里寫入讀取到的字元串，並返回一個Result&，它在讀取成功時包含讀取到的位元組數（和C/C++的getline()一樣），異常時包含一個錯誤。一般來說並不需要知道讀取到了多少個位元組，這個返回值一般都要被忽略，但是如果把.ok()去掉就通不過編譯，因為這樣就丟棄了read_line()返回的Result。ok()的作用是把Result&轉換為Option&，放棄Result里的錯誤信息，在出錯時統一用None表示，而Option並不是must_use，允許忽略。

use std::io;

let mut s=String::new();
io::stdin().read_line(mut s).
or_else(|e:io::Error|
println!("I/O Error: {}",e);
).ok();


or_else其實就是上面提到的and_then的反義詞，用法不再詳述，看代碼能理解就好

實際使用中，儘管標準庫提供了很多像and_then這樣的還算有用的異常處理函數，但多數情況下（包括標準庫自己）稍微複雜一點的一般都會自己寫個match（用法見第二段代碼，和其他函數式語言的match類似，比C系語言的switch更強大）來做，實際上就是條件分支，加上Rust沒有try catch，出錯後無法方便地跳轉，看上去Rust的異常處理是不是簡直和C一樣垃圾？

2、把異常信息往上傳，只要有一步可能出錯，就應該返回被Option或Result包裹著的值而不是祼的值。

fn print_is_odd(x:i32){
match x%2{
0 =&> println!("Even");
1 =&> println!("Odd");
_ =&> unreachable!();
}
}


這個match的最後一個分支（等效於default，單獨一個下劃線可以被視為變數名，充當placeholder，而不會引起unused variable的warning）如果省略的話就通不過編譯，即使我們知道邏輯上被match的表達式只可能是0或1，但編譯器不知道，它要求你必須窮盡32位整型的所有可能取值。這裡unreachable!()的效果是直接panic掉並輸出一些錯誤信息，表明你進入了一個邏輯上不可能進入的分支。

即使是沒有try catch，Rust還是有辦法優雅地跳轉：break和continue可以指定針對哪個循環，當然這不能解決所有跳轉，但至少對於多數C++/Java教程中作為論證try catch的重要性的反例代碼，Rust有辦法利用更靈活的break和continue把它們寫得和try catch差不多優雅

2016-10-15T13:16+08:00

2015-08-31T20:57+08:00

if( error state1 ) {
do something...
} else if( error state2 ) {
do something...
}


實際上就是所謂的 LBYL（Look Before You Leap）。這篇博文 Robust exception handling 這樣描述這種錯誤處理模式：

A common idiom in other languages, sometimes known as "look before you
leap" (LBYL), is to check in advance, before attempting an operation,
for all circumstances that might make the operation invalid.

回想一下自己閱讀過的 C 代碼，相信有不少用 LBYL 方式進行錯誤（異常）處理的吧（調用一個函數後，先根據函數返回值判斷函數是否調用成功。若是，則進行下一步；否，則轉入錯誤處理流程）。

try:
do something...
do something else...
...
except ...:
exception(s) handling


嗯。這種代碼執行流程和錯誤處理沒有團的那麼緊，看起來相對也清晰一些。實際上，我貼的第一篇博文和這一篇 Write Cleaner Python: Use Exceptions 都推薦使用 EAFP 來處理 Python 中的異常。

像 C 這種沒有內置異常機制、而且一旦錯誤情況不處理好程序就分分鐘 crash 的語言，慣常以函數返回值來表示異常情況。此種情況下，LBYL 可能就是最好的選擇——如果做的正確的話。此時，無所謂執行流程清晰與否。

而 Python 就不一樣了。異常機制是內置於語言中的，而且很多標準庫模塊都喜歡通過拋出異常來表示程序出錯了。況且，Python 代碼和 OS 之間還有 Python 的虛擬機，我們未處理的異常也不太會導致程序 crash 或「閃退」——你總能看到錯誤提示的。

關於使用 Exception 還是 return code，那就看語言本身有沒有完善的異常處理體系啊。以及，現有的代碼（特別是標準庫的代碼）是以什麼作為 best practice 的。

利益相關：僅學習過 C/C++/Python！把以前看到的一些零零碎碎關於異常處理的東東貼出來吧。

2015-09-01T11:52+08:00

2015-09-02T17:07+08:00

2015-09-07T08:50+08:00

7. 知乎上看到一些人評價c++的exception很難用，想問一下大家寫c++時怎麼處理錯誤？ - C++

2015-10-10T09:26+08:00

2015-10-20T20:39+08:00

2015-11-13T16:11+08:00

2016-03-21T13:39+08:00

2016-10-18T13:15+08:00

函數式語言的一個常見設計模式就是用monad做錯誤處理。這裡好處在於，錯誤處理的邏輯只要在monad instance那裡實現一遍，然後就不需要在每個call site考慮錯誤處理，減少boilerplate code，提升代碼的模塊性和可讀性。

放一個F#的相關slides：Railway Oriented Programming

以上是最簡單的「在單個monad中實現錯誤處理」，而函數式語言里，monad這個抽象還經常用來封裝各種其他類型的計算，比如帶狀態的計算、非確定性的計算等等，那麼為了進一步提升代碼的模塊性，我們會希望能夠像玩拼圖一樣，用一個monad表達錯誤處理、另一個monad表達帶狀態計算等，然後我的函數需要用到幾個功能，就把幾個monad拼接到一起。這就是monad transformer，比如在Haskell的transformers庫中，提供了ExceptT，可以給任意monad增添一層錯誤處理的功能。學習monad transformers的教程：https://www.cs.virginia.edu/~wh5a/personal/Transformers.pdf

try catch

　} catch (Error0 meow0) {

synchronous signal

Resource Acquisition Is Initialization

C的atexit on_exit