到底要在哪裏處理異常

通過了一些實踐和思考,我開始有點感受了,就在我被別人問到這個問題以後,我這樣總結到:
" 判斷異常要不要throws,關鍵看調用者是否關注這個異常;若不關注,則就地catch處理掉"

貌似有點指導意義了, 不過如何指導調用者是否關注呢?若你是少有參與設計,且只負責一小塊功能模塊的程序,這個問題對於你來講確實很差判斷.由於它的判斷是須要基於全局的,一般設計者要慎重考慮.那麼設計者是如何把握異常的處理呢,其中的原則又是什麼呢?

這裏我就本身的理解,總結一下以供參考.

原則1  throws業務流程異常

業務流程異常是指業務流程中預料到的異常而且要對此進行處理. 舉個ATM提款的例子來講明:

ATM提款後,都會有打印一個"回執"給用戶.但"回執"的紙張不是每次都夠用的(我就常常遇到這種破事),這中異常狀況一般都會在用戶插卡輸入正確的密碼以後,出現詢問"沒法打印回執,是否繼續?"的提示. 此時這異常就須要從檢查紙張的低層模塊中throws給業務邏輯處理模塊,再拋給界面處理模塊等待用戶處理.

 

也許這個例子對於I/O或格式轉換類的基礎異常可能不能徹底說明問題,那麼再看一個文件讀取的例子:

有個文件上傳的程序,須要用戶經過界面輸入要上傳的文件,此時是有可能出現文件不存在或文件被鎖定之類的問題的.所以,訪問文件I/O的低層模塊就須要把這類異常throws給調用者,同上面的例子同樣交給用戶處理.

 

由這個原則1能夠推理出下面一個原則.

原則2  低層被調用的模塊的異常通常都throws給它的調用者處理

注意,這裏強調一下是"通常",而不是全部狀況.什麼狀況原則2不適用呢?請看原則3

原則3  catch不影響業務流程的異常

不影響業務流程的異常是指嚴重級別比較低,只須要記錄甚至能夠徹底忽略的異常.一般不作特別的處理是不想中斷正常的業務進程.

 

此外,還補充一點,對於須要銷燬或釋放資源的業務邏輯中,異常的處理很須要經驗和技巧的,由於處理不當容易形成內存泄漏和低效率的問題,這塊我尚無成熟經驗.

 

本文轉自 http://zhongl.iteye.com/blog/122426