WCF - 抛出异常或FaultException？

Question

效率更高？抛出异常或抛出错误......我看到的方式是有两种情况：

1. 发生异常并被捕获，您是否抛出现有Exception或创建新FaultException并扔掉它？

2. 您自己的逻辑（例如用户名不能为空）需要将错误抛出为Exception或FaultException。您选择哪个？

基本上，哪种方式是最佳实践方式？我问，因为我记得在某处读到有关WCF装箱或拆箱的异常，并且它耗费了额外的资源等......所以我猜也是，这是更有效的方式？

Answer 1

来自WSDL合同视角，每个操作最多只能有一个响应。但是，您可以定义多个故障合同，这基本上告诉客户“预计由DataContractX定义的响应，或由FaultContractY或FaultContractZ定义的故障响应。”

使用FaultExceptions可以更好地控制WSDL的表示方式（或者针对已定义的WSDL编写兼容服务）。

如果您真的想要实现互操作性并且正在充分利用wsdl和soap来实现这一目标，那么您将需要使用FaultExceptions。如果您在仅.NET交互中使用WCF，您可以使用例外或故障异常，我认为性能差异不会很大（通过网络进行通信的次数比WCF运行时将异常包装到通用中更重要通过电线传输的故障）。

Answer 2

它可以取决于您希望处理异常的位置和方式。无论服务代码是否允许未处理的异常，客户端（无论平台）都将始终收到soap故障异常，该服务显式抛出FaultException或抛出FaultException的泛型版本。

是否要定义自定义故障异常以便更容易识别特定服务条件是一个设计问题。我的经验法则是当我希望客户端执行由该自定义故障触发的备用逻辑时，仅抛出自定义错误。验证之类的东西是一个灰色区域，因为您真的不希望所有详细的验证逻辑都由自定义故障驱动。我通常会创建一个自定义验证失败的错误，并将其包含在所有中的验证问题，它可以找到自定义错误的列表属性。

处理异常总是一个代价高昂的过程，但在服务端抛出FaultException或任何其他.NET异常之间没有真正的性能差异。

Answer 3

根据我的理解，如果您正在使用wsHttpBinding，并且如果您抛出.Net异常而不是FaultException，则Server-Client通道将处于故障状态，并且必须重新创建代理类对象，因为现有代理对象将无法使用因此，最佳做法可能是使用FaultException。

Answer 4

如果您只是使用＆＃39; Exception＆＃39;抛出异常，WCF服务将引发FaultExceptionin，除非您提及，否则客户端永远不会知道异常的根本原因 web.config中的<serviceDebug includeExceptionDetailInFaults="true"/>。如果您希望客户端知道异常背后的原因/自定义消息，请选择FaultException。拥有散乱类型的异常是最好的做法。