處理WCF異常/故障以及FaultException和IErrorHandler

Question

我有興趣爲我的WCF應用程序實現適當的異常處理。在谷歌快速搭車後，我遇到了兩種解決方案。

1. 爲客戶提供FaultExceptions。
2. 使用IErrorHandler的一般異常處理。

我沒發現什麼，雖然是結合了這兩種方法的實際例子 - 如果這甚至認爲是很好的做法。

我的想法：

投擲FaultExceptions用自己的詳細類型

throw new FaultException<StackOverflowFault>(
    new StackOverflowFault(StackOverflowFaultCode.Rules, 
     "This question is not considered as constructive.")); 

與IErrorHandler捕獲未處理的異常，並記錄它們。基於異常的類型

public bool HandleError(Exception ex) { 
    try { 
     SomeLogger.Error(ex.Message, ex.Source); 
     return true; 
    } catch (Exception) { 
     // Well, there was an exception handling the 
     // exception :(
     // -> Drop the exception and throw a new one 
     throw new Exception("Unknown exception occured."); 
    } 
} 

......並提供故障（不是一切爲了客戶的眼睛！）

public void ProvideFault(Exception error, MessageVersion version, ref Message fault){ 
    if(error is FaultException) { 
     fault = Message.CreateMessage(version, ((FaultException<StackOverflowFault>)error).Reason) 
    } else if(error is SqlException) { 
     // What would Jon Skeet do? 
    } 
} 

---

我的問題

這是否被認爲是好的做法？並且：如果我已經在適用於客戶端的應用程序中拋出FaultException - 是否有意義讓它們由IErrorHandler（自動執行）處理？

Answer 1

最佳做法是實施IErrorHandler。這是因爲：

1. 您的代碼不是唯一的潛在異常來源。您調用的方法（或錯誤）可能導致.NET異常。如果你沒有在某個地方處理這個異常，並且沒有使用IncludeExceptionDetailInFaults（你不應該在生產中），這看起來就像是服務崩潰。
2. 問題分離：由服務代碼調用的任何業務層都不應該引用WCF（System.ServiceModel），因此應拋出標準的.NET異常。保持業務層不知道其託管方式如何使其更具可移植性和可測試性。
3. [FaultContract]類型需要在[OperationContract]上指定。在較大的應用程序中，您希望將故障生成集中化......換句話說，要知道特定的IErrorHandler會返回一組特定的故障，以便您可以驗證合同故障類型是否正確。拋出契約的方法沒有明確支持的Fault類型是一個令人討厭的運行時錯誤。

您可以在所有服務方法中複製並粘貼try/catch塊來引發FaultException，但這是一種可怕的代碼異味，並且是IErrorHandler作爲行爲給予您的確切功能。因此改用IErrorHandler。

結合這兩種模式是可能的。例如，IErrorHandler根據需要處理FaultExceptions，但這不是常見的做法。