2019獨角獸企業重金招聘Python工程師標準>>>

1.是否需要已檢測異常

《Clean Code》一書對已檢測異常是持完全否定態度的。事實上，有很多人是不認可已檢測異常的，一方面，在目前的主流語言中，只有java提供了已檢測異常機制，那么這從反面證明已檢測異常并不是一種“必須”或者說是“優秀”的語言機制。已檢測異常的設計初衷是希望借助編譯期的檢查來強制異常處理，從而有助于構建出健壯的系統。但正如《Clean Code》一書所說，那些沒有已檢測異常的語言就不能構建健壯的系統么？顯然不是，也就是說已檢測異常并不是"看上去那么美"。另一方面，人們普遍認為引入已檢測異常的一個很大的代價就是違反了開閉原則。一旦底層的某個方法需要修改接口拋出一個已檢測異常，那么上層的所有調用接口都不能幸免，它們的接口或是實現也必然需要做出改動！再比如：一個較“底層”的方法拋出已檢測異常，如果上層方法對此異常也“無能為力”的話會怎樣呢？捕獲而不處理是肯定不正確的。而如果再拋出就需要有一個合適的異常來包裹一下以便符合當前方法的抽象級別。

2.對于一個異常應該根據什么原則來確定它應該是已檢測異常還是未檢查異常？

實際上，如果在回答第一個問題時，我們選擇了不使用已檢測異常的話，也就不存在這個問題了。但是在廣泛使用已檢測異常的系統里，知道怎樣區分已檢測異常和未檢測異常是非常必要的。一般來說：從調用者的角度去看，已檢測異常是那些完全有理由能“預見”或是“重現”的異常情況。那這也正意未著方法本身明確要求調用者不能忽視（既然它已經預見到可能會發生了）這些異常情況。基于這樣的準則，我們說：幾乎所有的業務異常（有深刻業務含義的異常）都應該是已檢測異常。除此之外都應該屬于程序性錯誤，也就是未檢測異常。
這看起來很簡單，但是卻忽略了一個問題：抽象級別的問題。現在的系統都是依賴各種框架或組件構建起來的。在框架和組件級別，一些“當然”業務上的已檢測異常，在上層看來是很“底層”的“技術”問題。比如，在一個文件處理框架里，FileNotFoundException是一個很自然的“業務”異常，因而是一個已檢測異常。但是對于調用者來說，如果對此異常也“無能為力”會怎樣呢？捕獲而不處理是肯定不正確的。而如果再拋出就需要有一個合適的異常來包裹一下以便符合當前方法的抽象級別。這樣看，處理已檢測異常確實是很“勞神”的（當然你可以說這正是它的優點）。

3.視圖層的異常統一處理方法
當異常一直浮升到視圖層時，就需要考慮以何種方式通知用戶系統出現了問題。當發生異常時跳轉到統一的異常處理頁面顯示錯誤信息是一種普遍的做法。至于說在當前頁面彈出對話框顯示異常的形式可能會更加友好一些。但是由于頁面請求既有http請求又有ajax請求的話，彈出對話框的方式可能有些技術上的困難。　

轉載于:https://my.oschina.net/pangzhuzhu/blog/326984

總結

以上是生活随笔為你收集整理的关于系统异常设计的再思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。