概述

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

異常安全

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

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

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

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

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

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

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

Python 中的異常處理機制

 首先，Python 是一門面向對象語言，所有的異常類都是通過繼承BaseException類來實現的，我們亦可以通過相應的繼承來實現自定義的異常類，比如在工作流調度中使用AirflowException，具體實現可以直接看Airflow的源碼。

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

1. IO異常：由網絡抖動、磁盤文件位置變更、數據庫連接變更等引起的IO異常問題。
2. 運行期異常：由于計算或者傳輸的參數參數類型有誤、參數值異常等等發生在運行期的異常，都統一被稱為運行期異常。正常來說，IO上的異常我們都要有相應的try-catch-finally機制，在Python也就是如下實現：

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

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

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

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

舉一個例子：

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() 

 你看這里的返回應該是什么呢?

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

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

一個段正確的處理方式應該是這樣的：

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

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

R 中的異常處理機制

R和Python***的不同就是 R 本質上是一門強動態類型的非純函數式編程語言(所謂非純即存在副作用)而非面向對象語言。從函數式編程語言的角度上講，R和Erlang、LISP的關系比較近一些。

既然是函數式語言，處理異常也是通過函數式的，而非直接通過面向對象的方式。R 從語法上來看就略顯突兀(花括號函數式語言的一大通病)：

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

如果這段用Python來表達就變成：

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

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

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

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

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

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

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

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