Web 服务中的例外
-
09-06-2019 - |
题
我的小组正在开发一个基于服务的 (.NET WCF) 应用程序,我们正在尝试决定如何处理内部服务中的异常。我们应该抛出异常吗?返回序列化为 XML 的异常?只返回错误码?
请记住,用户永远不会看到这些异常,它仅适用于应用程序的其他部分。
解决方案
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!"));
}
}
其他提示
那么,为什么不直接抛出标准的 SOAPException 呢?错误代码和序列化 XML 的问题在于,它们都需要额外的逻辑来识别错误确实发生了。仅当您需要在 Web 服务的另一端进行专门的日志记录或逻辑时,这种方法才有用。这样的示例将返回一个标志,表示“可以继续”,并带有错误异常报告。
不管你如何抛出它,它都不会让工作变得更容易,因为调用方仍然需要认识到存在异常并处理它。
我有点困惑,我并不是轻率——您说您一方面想要返回序列化为 XML 的异常,另一方面用户永远不会看到异常。谁会看到这些例外情况?
通常我会说使用 WCF 故障合约。
Phil,应用程序的不同部分使用 WCF 相互调用。我所说的“返回序列化为 XML 的异常”是指该函数的返回值将是一个异常对象。成功将用 null 表示。
我认为这不是正确的选择。
WCF 故障契约听起来不错,但我对它们一无所知。现在正在检查谷歌。
我会避免将异常直接发送回客户端,除非您同意发回这么多详细信息。
我建议使用 WCF 错误来传输错误消息和代码(可用于对接收方做出重试、错误输出等决定),具体取决于错误是发送方还是接收方。
这可以使用FaultCode.CreateReceiverFaultCode 和FaultCode.CreateSenderFaultCode 来完成。
我现在正在经历这个过程,但在 WCF 错误生成的 SOAP 1.1 响应中似乎遇到了一个令人讨厌的障碍。如果您有兴趣,可以在这里查看我的问题: