關于異常的合理處理方式

 最近公司内要搞一個平台，内部涉及到自動化運維的一部分，趁着十一這兩天玩過回來在學習expect，看tcl一章異常處理的時候，突然想到個問題，異常合理處理方式的問題。

異常合理從技術上分2種處理方式。

1、抛exception的方式；

2、傳回值判斷的方式；

其實任何系統中，都不可能隻用一種處理方式，不然這個就過猶不及的，總結了一下比較合理的方式。

傳回值判斷的方式比較适合于正常邏輯的一部分，哪怕對于某個業務功能來說，它可能影響很大，比如檔案不完整，賬戶不存在，密碼不正确，金額為負數等。

抛異常則适合于出錯了有可能無法繼續往下運作的場景，比如配置檔案不存在，資料庫連接配接不上，網絡斷開。此時調用者必須仔細思考是否捕獲異常，清一色往上抛是不負責的做法。

除此之外，有可能會出現的情況就是一個程式中有可能會抛出七八種異常，這個時候，如果都通過抛出異常的方式讓外部捕獲，這個實作就比較差了，而且并不一定所有的異常都是不可修複的。

還有很重要的一點，對于可能傳回null的場景，内部沒有檢查是否為null，而是依賴于運作時的NullPointerException總覺得不是一種特别合理的方式。因為NullPointerException是個繼承于RuntimeException，這使得異常捕獲是可選的。真到運作時抛出很可能會導緻業務中止而不一緻。對于這個null，更合理的做法應該是對于邏輯已知有可能為null而導緻外部調用者使用null傳回值可能會異常的（比如DES/base64加解密），或許更好的方式是抛出一個包裝的受檢異常，強行要求外部調用者捕獲，而不是外部調用者判斷傳回值是否為null（應用開發者很有可能是不會去看源碼的），這可能是更好的方式。對于非open source程式，在自定義的受檢異常上包裝自定義的錯誤代碼這會更加的清晰。

花若盛開，蝶自飛來，你若精彩，幸福開懷！2020年12月11日-18日