概述

異常處理，是編程語言或計算機硬件里的一種機制，用于處理軟件或信息系統(tǒng)中出現(xiàn)的異常狀況(即超出程序正常執(zhí)行流程的某些特殊條件)。Python和R作為一門編程語言自然也是有各自的異常處理機制的，異常處理機制在代碼編寫中扮演著非常關(guān)鍵的角色，卻又是許多人容易混淆的地方。對于異常機制的合理運用是直接關(guān)系到碼農(nóng)飯碗的事情!所以，本文將具體介紹一下Python和R的異常處理機制，闡明二者在異常處理機制上的異同。

異常安全

在了解Python和R的異常機制之前，我們有必要了解一下異常安全的概念。

根據(jù)WikiPedia的文獻(xiàn)，一段代碼是異常安全的，如果這段代碼運行時的失敗不會產(chǎn)生有害后果，如內(nèi)存泄露、存儲數(shù)據(jù)混淆、或無效的輸出。我們可以知道一段代碼的異常安全通常分為下面五類：

異常安全通常分為5個層次：

1. 失敗透明：如果出現(xiàn)了異常，將不會對外進(jìn)一步拋出該異常。(一般比較復(fù)雜)
2. 強異常安全：可以運行失敗，不過數(shù)據(jù)會回滾到代碼運行前(無副作用)
3. 基本異常安全：運行失敗導(dǎo)致的數(shù)據(jù)變更，使得代碼運行前后數(shù)據(jù)不一致了(有副作用)
4. 最小異常安全：運行失敗保存了無效數(shù)據(jù)，但是還不會引起崩潰，資源不會泄露(進(jìn)程不會掛)
5. 異常不安全：沒有任何保證(進(jìn)程可能會掛掉)

從上述的5個層次來看，我們可以知道，在平時寫代碼的時候，對數(shù)據(jù)庫、文件、網(wǎng)絡(luò)等的IO操作都是需要盡量保證無副作用的，也就是強異常安全。具體來說就是，RDBS操作在失敗的時候需要回滾機制、所有IO操作在***要保證IO連接資源關(guān)閉。

其實和多數(shù)語言的異常機制的語法是類似的：Python和R都是通過拋出一個異常對象或一個枚舉類的值來返回一個異常;異常處理代碼的作用域由try開始，以***個異常處理子句(catch, except等)結(jié)束;可連續(xù)出現(xiàn)若干個異常處理子句，每個處理特定類型的異常。***通過finally子句，無論是否出現(xiàn)異常它都將執(zhí)行，用于釋放異常處理所需的一些資源。

下面將具體介紹二者的異常處理機制。

Python 中的異常處理機制

 首先，Python 是一門面向?qū)ο笳Z言，所有的異常類都是通過繼承BaseException類來實現(xiàn)的，我們亦可以通過相應(yīng)的繼承來實現(xiàn)自定義的異常類，比如在工作流調(diào)度中使用AirflowException，具體實現(xiàn)可以直接看Airflow的源碼。

事實上，這些在我們代碼處理范圍內(nèi)的異常其實就是可以分成兩個部分：

1. IO異常：由網(wǎng)絡(luò)抖動、磁盤文件位置變更、數(shù)據(jù)庫連接變更等引起的IO異常問題。
2. 運行期異常：由于計算或者傳輸?shù)膮?shù)參數(shù)類型有誤、參數(shù)值異常等等發(fā)生在運行期的異常，都統(tǒng)一被稱為運行期異常。正常來說，IO上的異常我們都要有相應(yīng)的try-catch-finally機制，在Python也就是如下實現(xiàn)：

try: 
   do something with IO 
except: 
   do something without IO 
finally: 
   close IO 

 這里容易犯的一個錯誤就是在except中又引入了新的IO操作，比如在except中又引入了一個API的POST請求或者數(shù)據(jù)庫寫操作等等，這樣如果在except階段又發(fā)生了異常，將導(dǎo)致異常信息的丟失。

另一方面，對于可能的運行期異常則需要我們根據(jù)具體應(yīng)用場景的需求來做相應(yīng)的處理，一般就是遇到一個新的問題加一個新的異常捕獲機制，當(dāng)然這里也就考驗到碼農(nóng)程序設(shè)計的功利，是否能夠未雨綢繆。比如數(shù)組長度的檢查，傳入字典的Key檢查等等。Python本身提供了豐富的異常處理類型并且易于拓展，正確使用將可以顯著提升程序的魯棒性(保住碼農(nóng)的飯碗)。

使用try-catch-finally機制是足夠簡單的，但是在混入return和rasie操作之后，事情就看起來變得有點復(fù)雜。

舉一個例子：

def test(): 
    try: 
        a = 1/0 
    except: 
        a = 0 
        raise(ValueError,"value error, the division must greater than 0") 
        return a 
    finally: 
        a = 1 
        return a 
test() 

 你看這里的返回應(yīng)該是什么呢?

其實，這里的返回***應(yīng)該是 1，而except中raise的異常則會被吃掉。這也是許多人錯誤使用finanlly的一個很好的例子。

Python在執(zhí)行帶有fianlly的子句時會將except內(nèi)拋出的對象先緩存起來，優(yōu)先執(zhí)行finally中拋出的對象，如果finally中先拋出了return或者raise，那么except段拋出的對象將看起來被吃掉了。

一個段正確的處理方式應(yīng)該是這樣的：

try: 
    do IO 
    info = {"status":200} 
except: 
    info = {"status":400} 
finally: 
    try: 
        write log(info) 
    except: 
        raise(SomeError,"error message") 
    close IO 

 具體的調(diào)用棧的過程可以參考這個更加生動的例子：

R 中的異常處理機制

R和Python***的不同就是 R 本質(zhì)上是一門強動態(tài)類型的非純函數(shù)式編程語言(所謂非純即存在副作用)而非面向?qū)ο笳Z言。從函數(shù)式編程語言的角度上講，R和Erlang、LISP的關(guān)系比較近一些。

既然是函數(shù)式語言，處理異常也是通過函數(shù)式的，而非直接通過面向?qū)ο蟮姆绞健 從語法上來看就略顯突兀(花括號函數(shù)式語言的一大通病)：

tryCatch({ 
  doStuff() 
  doMoreStuff() 
}, some_exception = function(se) { 
  recover(se) 
}) 

如果這段用Python來表達(dá)就變成：

try: 
  doStuff() 
  doMoreStuff() 
except SomeException, se: 
  recover(se) 

 事實上正確運用 R 的異常處理機制反而是比較負(fù)擔(dān)小的一種方式：(R 還支持用中文字符集命名變量)

tryCatch({ 
  結(jié)果 <- 表達(dá)式 
}, warning = function(w) { 
    warning() 
  ... # 運行期異常 
}, error = function(e) { 
    stop() 
  ... # IO異常 
}, finally { 
    on.exit() 
  ... # 資源回收 
} 

 下面是 Hadley 大神對R的異常處理機制優(yōu)點的分析：

One of R’s great features is its condition system. It serves a similar purpose to the exception handling systems in Java, Python, and C++ but is more flexible. In fact, its flexibility extends beyond error handling–conditions are more general than exceptions in that a condition can represent any occurrence during a program’s execution that may be of interest to code at different levels on the call stack. For example, in the section “Other Uses for Conditions,” you’ll see that conditions can be used to emit warnings without disrupting execution of the code that emits the warning while allowing code higher on the call stack to control whether the warning message is printed. For the time being, however, I’ll focus on error handling.

The condition system is more flexible than exception systems because instead of providing a two-part division between the code that signals an error and the code that handles it, the condition system splits the responsibilities into three parts–signaling a condition, handling it, and restarting. In this chapter, I’ll describe how you could use conditions in part of a hypothetical application for analyzing log files. You’ll see how you could use the condition system to allow a low-level function to detect a problem while parsing a log file and signal an error, to allow mid-level code to provide several possible ways of recovering from such an error, and to allow code at the highest level of the application to define a policy for choosing which recovery strategy to use.

我的理解是R通過條件機制，然我們可以選擇性的在低階函數(shù)中把warning吃掉，這樣就不至于影響高階函數(shù)的運行?條件機制將異常分為三階段而不是兩階段：

1. 異常信號捕獲
2. 異常處理
3. 重啟機制。

并且我們還可以看到在異常處理中，如何在中階函數(shù)中恢復(fù)低階函數(shù)的Error,并且在高階函數(shù)中選擇一定的恢復(fù)策略。

這段貌似個人理解有誤，還請看官指正。