Web 服务中的例外

Question

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

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

Answer 1

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

您可以使用以下方法声明自定义 SOAP 错误 FaultContract 合约接口中的属性：

例如：

[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!"));
    }
}

Answer 2

那么，为什么不直接抛出标准的 SOAPException 呢？错误代码和序列化 XML 的问题在于，它们都需要额外的逻辑来识别错误确实发生了。仅当您需要在 Web 服务的另一端进行专门的日志记录或逻辑时，这种方法才有用。这样的示例将返回一个标志，表示“可以继续”，并带有错误异常报告。

不管你如何抛出它，它都不会让工作变得更容易，因为调用方仍然需要认识到存在异常并处理它。

Answer 3

我有点困惑，我并不是轻率——您说您一方面想要返回序列化为 XML 的异常，另一方面用户永远不会看到异常。谁会看到这些例外情况？

通常我会说使用 WCF 故障合约。

Answer 4

Phil，应用程序的不同部分使用 WCF 相互调用。我所说的“返回序列化为 XML 的异常”是指该函数的返回值将是一个异常对象。成功将用 null 表示。

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

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

Answer 5

我会避免将异常直接发送回客户端，除非您同意发回这么多详细信息。

我建议使用 WCF 错误来传输错误消息和代码（可用于对接收方做出重试、错误输出等决定），具体取决于错误是发送方还是接收方。

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

我现在正在经历这个过程，但在 WCF 错误生成的 SOAP 1.1 响应中似乎遇到了一个令人讨厌的障碍。如果您有兴趣，可以在这里查看我的问题：

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