什麼是您的自定義異常層次結構？

Question

我的問題是：你將如何在你的應用程序中創建異常層次結構？

設計一個應用程序的架構， 從我的角度來看，我們可以有三種例外：

• 內置的（如：InvalidOperationException異常）
• 定製的內部系統故障（數據庫事務失敗上提交，DbTransactionFailedException）
• 定製業務異常（BusinessRuleViolationException）

氯屁股層次：

• 異常
  • MyAppInternalException
    • DbTransactionFailedException
    • MyServerTimeoutException
    • ...
  • MyAppBusinessRuleViolationException
    • UsernameAlreadyExistsException
    • ...

只有MyAppInternalException & MyAppBusinessRuleViolationException將被逮住。

Answer 1

從類型F繼承的異常類型E的真正好處顯然是當E被一個模塊捕獲時，它並不明確地知道E是什麼，但是知道F.假設繼承有意義，模塊有一個合理的希望能夠根據E例外情況採取正確的糾正措施。

因此，我傾向於根據如何合理處理異常來對異常進行分類。例如，典型的業務流程可能使用類似於：

• ConfigurationException - 可通過更改配置文件修復的事情。例如。配置無法解析或不一致。適當的響應是警告用戶修改配置（如果可能，請提供有用的提示）。
• InfrastructureException - 可能偶爾會出現程序控制之外的資源出錯的問題，例如遠程服務器等。適當的響應通常是在暫停後斷開連接並重試，並放棄失敗太多的情況。
• DataException - 傳入數據中的錯誤。適當的迴應是記錄投訴（可能還有數據）並忽略此消息。

當然這些可以分類。但是，在這個層面上的區分對於更接近異常源的模塊通常更有用。如果一個異常一直到主模塊，那麼通常只有幾個可能的操作，並且最容易在這些操作和它們響應的語句之間建立一對一的對應關係。

Answer 2

「UsernameAlreadyExistsException」

我想你不應該使用異常來控制應用程序的正常流動。即這是一個常規業務案例，不應該作爲例外出現。在正確的應用程序設計中沒有MyAppBusinessRuleViolationException。

問候，