首页 / 知识

关于.net：Web服务中的异常

2023-04-13 23:24:00

Exceptions in Web Services

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

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

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

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

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

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

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

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

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

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

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

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

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

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

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

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

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

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