我的小组正在开发基于服务的(.NET WCF)应用程序，我们正在尝试决定如何处理内部服务中的异常。我们应该抛出异常吗？返回序列化为XML的异常？只是返回错误代码？

请记住，用户永远不会看到这些异常，仅适用于应用程序的其他部分。

解决方案

回答

我有点困惑，我不是很随便-我们说我们想一方面返回序列化为XML的异常，而另一方面用户永远不会看到该异常。谁会看到这些例外？

通常，我会说要使用WCF故障合同。

回答

好吧，为什么不仅仅抛出标准的SOAPExceptions？错误代码和序列化XML的问题在于，它们都需要添加的逻辑来识别实际上确实发生了错误。仅当我们需要在Web服务的另一端进行专门的日志记录或者逻辑处理时，这种方法才有用。这样的示例将返回一个带有错误异常报告的标记，表示"可以继续"。

不管我们如何抛出它，它都不会使工作变得容易，因为调用方仍需要认识到存在异常并对其进行处理。

回答

Phil，应用程序的不同部分使用WCF相互调用。通过"将序列化为XML的返回异常"，我的意思是该函数的返回值将是一个异常对象。成功将由null表示。

我认为这不是正确的选择。

WCF故障合同听起来不错，但是我对它们一无所知。现在检查谷歌。

回答

WCF使用" SoapFaults"作为将异常从服务传输到客户端或者从客户端传输到服务的本机方式。

我们可以在合同界面中使用FaultContract属性来声明自定义SOAP错误：

例如：

[ServiceContract(Namespace="foobar")]
interface IContract
{
    [OperationContract]
    [FaultContract(typeof(CustomFault))]
    void DoSomething();
}

[DataContract(Namespace="Foobar")]
class CustomFault
{
    [DataMember]
    public string error;

    public CustomFault(string err)
    {
        error = err;
    }
}

class myService : IContract
{
    public void DoSomething()
    {
        throw new FaultException<CustomFault>( new CustomFault("Custom Exception!"));
    }
}

回答

我会避免将异常直接发送回客户端，除非我们可以将这么多的详细信息发送回去。

我建议使用WCF故障来传输错误消息和代码(可以用来决定接收方重试，出错等)，具体取决于发送方或者接收方是否有故障。

可以使用FaultCode.CreateReceiverFaultCode和FaultCode.CreateSenderFaultCode来完成。

我现在正在经历此过程，但是在WCF错误生成的SOAP 1.1响应中遇到了麻烦。如果我们有兴趣，可以在这里查看我的问题：

.NET WCF错误生成不正确的SOAP 1.1错误代码值