2

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

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

4

5 回答 5

3

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!"));
    }
}
于 2008-09-02T17:59:04.307 回答
2

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

无论您如何抛出它，它都不会使工作变得更容易，因为调用方仍然需要识别存在异常并进行处理。

于 2008-09-02T17:51:34.027 回答
1

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

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

于 2008-09-02T17:47:54.397 回答
0

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

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

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

于 2008-09-02T17:55:36.937 回答
0

我会避免将异常直接发送回客户端，除非您对发送回的这么多细节感到满意。

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

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

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

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

于 2008-09-15T17:47:46.530 回答