处理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，但这不是常见的做法。