例外處理實務做法（3）：Designing for Recovery

Dec. 24 10:10~11:20

 

今天繼續介紹Rebecca J. Wirfs-Brock女士2006年在IEEE Software上發表的另外一篇文章《Designing for Recovery》所建議的例外處理作法，這裡可以下載作者提供的原文。

在〈例外處理實務做法（1）：Toward Exception-Handling Best Practices〉，Teddy介紹了Rebecca 提出的9點例外處理實務做法。今天則是針對「如何讓自己的系統可以從錯誤中恢復正常」的角度，來探討例外處理策略。

 

1. 忽略請求

請注意這裡提到的做法是「忽略請求（ignore the request）」不是「忽略例外（ignore the exception）」。在某些特殊例外狀況，採取忽略請求的策略可以有助於系統恢復正常。例如，訂票系統突然在連續假日之前湧入大量的訂票請求，或是被駭客以「阻斷服務」攻擊。在這種情況之下，系統採取忽略請求的作法，雖然可能會降低系統服務的水準，但至少可以讓系統不要死當，有機會可以慢慢復原。

***

2. 承認失敗

承認失敗（admitting failure）就是所謂的fail fast，只要是發生例外就直接將例外往上傳，也不去管什麼系統狀態正不正確，可以不可重試（retry）的問題。基本上這種作法談不上什麼「為了復原而設計」，因為整個系統狀態可能根本就不對了，要復原變得相對困難，但也並非不可能。

在fail fast的策略之下還想要做到狀態回復，就必須要讓有足夠context的人來負責例外處理。例如，系統的controller呼叫一個信用卡授權元件，這個元件三不五時會當掉，導致整個系統停止運作。為了解決這個問題，controller可以再呼叫這個元件的時候，每次都重新啟動一個process或是JVM，這樣子就算是信用卡授權元件當機，也只會影響到自己的process/JVM，而不會讓整個系統都當掉。

***

3. 放棄

放棄（resign）基本上和fail fast一樣，就是承認失敗，丟出例外。唯一的不同就是放棄還需要保證系統狀態是正確的，所以要做一些cleanup的動作。Rebecca把fail fast的失敗稱為failure，而resign的失敗稱為definite failure，以資區別。

***

4. 聰明的重試

如果造成錯誤的狀態只是短暫的現象，則重試（retry）就有很大的機會可以讓系統繼續運作下去。網頁無法載入的時候大家第一個反應是什麼？一定是按下瀏覽器的「重新載入（reload）」按鈕，這就是一種手動的重試。

採用重試策略的時候，需要考慮最多重試幾次、多久重試一次等問題，通常做這些決定並不容易。最常見的作法是：連續重試三次，如果都失敗就放棄，但這種做法並不一定都會成功。有個朋友告訴Teddy 一個實際案例，他們有一個銀行業的客戶向他們抱怨，他們的某監控系統每天早上的時候都處於斷線狀態。查了好久終於發現，原來是每天晚上銀行的主機在執行大量的批次處理工作，導致有一段時間CPU負載很高，對於監控系統的連線要求沒有回應。雖然系統具有連續重試三次的功能，但是由於在短時間內重試，CPU依舊處於高負載狀態，系統還是沒有回應，所以造成白天客戶上班的時候，發現監控系統處在離線的狀態。

由以上例子可知，聰明的重試需要了解應用程式的執行環境與運算特性，才能夠發揮最好的效果。

5. 拖客戶和使用者下水

有時候失敗、放棄、自動重試都不可行或是不被允許，這時候就必須向更加聰明的人類求救，讓客戶或是使用者來決定處理方式。例如，印表機卡紙，就算是系統自動重試N次還是沒用，需要使用者先排除卡紙的狀態。另外還有想是要存檔的時候空間不足，這時候就需要詢問使用者，是要自行清出空間之後然後重試，還是要將檔案改存到其他的空間裡面。

採用這種策略的時候，記得要提供使用者足夠明確的選項與說明資訊，否則使用者也不知道要如何選擇與協助，讓系統繼續運作下去。

***

6. 向「高人」求援

當前面幾種策略都試過，依舊無法讓系統恢復正軌，這時候就必須要向外求援（appealing to a higher authority）。例如，找IT部門的系統管理員來幫忙，或是將產品送回給廠商維修。

向外求救之前，系統最好能夠提供足夠的除錯訊息，幫助這些「高人」縮短修復的時間。

***

友藏內心獨白：6個策略護一生。