對服務Exception設計的思考
在對接項目設計接口時，對異常設計有點疑問:
- 讀接口要不要拋出業務異常?
- 爲什麼拋出的異常都是
Runtime的異常？ 什麼時候應該用Checked Exception？ - 異常何時捕獲最佳?
要回答這一系列問題，並不是一個容易的事情。
首先嚐試回答Checked Exception vs Runtime Exception?
從代碼形式上看Checked Exception必須明確捕獲進行處理，RuntimeException則不然。那這兩種異常應該如何使用呢?
我比較贊同Effective Java書中的一個建議:
Item 58: Use checked exception for recoverable conditions and runtime exceptions for programming errors
然而在實踐過程中，在內部設計API的時候即便可以重試通過的情況，我們也是通過RuntimeException進行實現的。
總結來說，儘可能選擇RuntimeException，在提供需要資源的服務可以使用Checked Exception來幫助調用者更好的處理。
第二個問題，讀接口應該拋出業務異常嗎?
這個問題應該回歸到業務異常的本身定義。違背業務規則的操作就會拋出業務異常。讀本身並不會改動數據，也就不會涉及業務異常。此外，之前總結的參數異常一定是靜態的，這個對嗎？從定義上來講，是靜態還是需要讀取一些資源才能判斷不重要，重要的是校驗參數的合法性。
第三個問題，異常什麼時候捕獲？
異常有兩個作用: 提供阻斷信號 和 阻斷信息。我們如果可以通過處理阻斷進行自動處理，就可以在需要的時候進行捕獲；如果需要阻斷的信息，一般來說遵守延遲捕獲的原則，在對外服務時統一處理即可。
參考資料:
- Effective Java
- 如何優雅的處理異常