概述

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

異常安全

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

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

異常安全通常分為5個(gè)層次：

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

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

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

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

Python 中的異常處理機(jī)制

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

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

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

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

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

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

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

舉一個(gè)例子：

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)該是什么呢?

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

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

一個(gè)段正確的處理方式應(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)用棧的過(guò)程可以參考這個(gè)更加生動(dòng)的例子：

R 中的異常處理機(jī)制

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

既然是函數(shù)式語(yǔ)言，處理異常也是通過(guò)函數(shù)式的，而非直接通過(guò)面向?qū)ο蟮姆绞?。R 從語(yǔ)法上來(lái)看就略顯突兀(花括號(hào)函數(shù)式語(yǔ)言的一大通病)：

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

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

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

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

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

 下面是 Hadley 大神對(duì)R的異常處理機(jī)制優(yōu)點(diǎn)的分析：

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通過(guò)條件機(jī)制，然我們可以選擇性的在低階函數(shù)中把warning吃掉，這樣就不至于影響高階函數(shù)的運(yùn)行?條件機(jī)制將異常分為三階段而不是兩階段：

1. 異常信號(hào)捕獲
2. 異常處理
3. 重啟機(jī)制。

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

這段貌似個(gè)人理解有誤，還請(qǐng)看官指正。