7

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

  1. 发生异常并被捕获，您是抛出现有的Exception还是创建新的FaultException并抛出？

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

基本上，哪种方式是最佳实践方式？我之所以问，是因为我记得在某处读过有关 WCF 装箱或拆箱异常的信息，它会花费额外的资源等等......所以我也猜想，哪种方式更有效？

4

4 回答 4

13

从 WSDL 契约视角来看，每个操作最多可以有一个响应。但是，您可以定义多个故障契约，这基本上告诉客户端“期望由 定义的响应，或由orDataContractX定义的故障响应”。FaultContractYFaultContractZ

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

如果您真正尝试实现互操作性并充分利用 wsdl 和 soap 来实现这一点，您将需要使用 FaultExceptions。如果您在仅 .NET 的交互中使用 WCF，则可以使用异常或故障异常，我认为性能差异不会很大（通过网络进行通信比 WCF 运行时将异常包装成泛型更重要的数量级有线传输故障）。

于 2011-05-19T17:08:29.503 回答
8

它可能取决于您希望处理异常的位置和方式。无论服务代码允许未处理的异常、服务显式抛出 FaultException 还是抛出通用版本的 FaultException，客户端（无论平台如何）都将始终接收到 soap 错误异常。

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

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

于 2011-05-19T17:09:56.837 回答
2

据我了解，如果您使用的是 wsHttpBinding 并且抛出 .Net 异常而不是 FaultException，则服务器-客户端通道将处于故障状态，并且必须重新创建代理类对象，因为现有代理对象将不可用。所以最好的做法可能是使用 FaultException。

于 2014-03-31T07:48:28.867 回答
0

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

于 2017-08-14T11:48:33.963 回答