WCF - 引发异常或故障异常？
什么更有效率？抛出异常或抛出错误...我认为有两种情况：
发生异常并被捕获，您是抛出现有的
异常还是创建一个新的>FaultException并抛出该异常？您自己的逻辑（例如用户名不能为空）需要抛出异常或错误异常。你选择哪一个？
基本上，哪种方法是最佳实践方法？我问这个问题是因为我记得在某处读过有关 WCF 装箱或拆箱异常的内容，并且它会花费额外的资源等......所以我也想，哪种方法更有效？
What's more efficient? Throwing an exception or throwing a fault... the way I see it is that there's 2 scenarios:
An exception occurred and is caught, do you throw that existing
Exceptionor create a newFaultExceptionand throw that?Your own logic (such as username can't be blank) needs to throw an error either as an Exception or FaultException. Which do you choose?
Basically, which way is the best practice way? I ask because I remember reading somewhere about WCF boxing or unboxing exceptions and it costing additional resources and such like... so I guess also, which is the more efficient way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
从 WSDL 契约的角度来看，每个操作最多可以有一个响应。但是，您可以定义多个故障契约，这基本上告诉客户端“期望由
DataContractX定义的响应，或者由FaultContractY或FaultContractZ< 定义的故障响应/代码>。”使用FaultExceptions 可以让您更好地控制WSDL 的表示方式（或者根据已定义的WSDL 编写兼容的服务）。
如果您真正尝试实现互操作性并充分利用 wsdl 和soap 来实现此目的，您将需要使用FaultExceptions。如果您在仅 .NET 交互中使用 WCF，则可以使用异常或故障异常，我认为性能差异不会很大（通过网络进行通信比 WCF 运行时将异常包装到通用中更重要）线路传输故障）。
Coming from a WSDL Contract Perspective, each operation can can have at most one response. However, you can define multiple fault contracts, which basically tells a client "Expect either a response defined by
DataContractX, or a fault response defined byFaultContractYorFaultContractZ."Using FaultExceptions allows you finer control over how your WSDL is represented (or in writing a compliant service against an already defined WSDL).
If you are truly attempting to achieve interoperability and are fully leveraging wsdl and soap to achieve this you will need to use FaultExceptions. If you are using WCF in a .NET only interaction you can use Exceptions or Fault Exceptions, I don't think the performance difference will be significant (Communicating over the network is order of magnitudes more significant than the WCF runtime wrapping Exceptions into a Generic Fault for transmission over the wire).
这可能取决于您希望处理异常的位置和方式。无论服务代码允许未处理的异常、服务显式抛出FaultException还是抛出FaultException的通用版本，客户端（无论平台如何）都将始终收到soap错误异常。
是否要定义自定义故障异常以更轻松地识别特定服务条件是一个设计问题。我的经验法则是，仅当我希望客户端执行由自定义错误触发的备用逻辑时，才抛出自定义错误。像验证这样的东西是一个灰色区域，因为您确实不希望所有详细的验证逻辑都由自定义错误驱动。我通常会创建一个自定义验证失败故障，并将其包含所有它可以找到的验证问题作为自定义故障的列表属性。
处理异常始终是一个成本高昂的过程，但在服务端抛出FaultException 或任何其他.NET 异常之间没有真正的性能差异。
It can depend on where and how you want the exception handled. A client (regardless of platform) will always receive a soap fault exception whether the service code allows for unhandled exceptions, the service explicitly throws a FaultException or throws the generic version of FaultException.
Whether you want to define custom fault exceptions to make it easier to identify specific service conditions is a design concern. My rule of thumb is to only throw custom faults when I expect the client to perform alternate logic triggered by that custom fault. Something like validation is a grey area because you really don't want all your detailed validation logic to be driven by custom faults. I generally create a single custom validation failed fault and have it include all the validation issues it can find as list property of the custom fault.
Handling exceptions is always a costly process but there is no real performance difference between throwing a FaultException or any other .NET exception on the service side.
根据我的理解，如果您使用 wsHttpBinding 并且抛出 .Net 异常而不是FaultException，则服务器-客户端通道将处于故障状态，并且必须重新创建代理类对象，因为现有代理对象将不可用。因此，最佳实践可能是使用FaultException。
From my understanding if you are using wsHttpBinding and if you throw a .Net exception rather than a FaultException the Server-Client channel will be at faulted state, and the proxy class object will have to be recreated as the existing proxy object will be unusable. So the best practice might be to use FaultException.
如果您只是使用“Exception”抛出异常，WCF服务将在后面引发FaultException，并且客户端永远不会知道异常的根本原因，除非您提到
web.config 中的
If you simply throw an exception using 'Exception', WCF service will raise FaultExceptionin behind and the root cause of exception will never be known by client unless you mention
<serviceDebug includeExceptionDetailInFaults="true"/>in web.config. If you wish client to know the reason/custom message behind the exception, prefer FaultException. It's a best practice to have straggly typed exception.