WCF-在服务中引发FaultExceptions的开销 [英] WCF - Overhead of throwing FaultExceptions within your service
问题描述
我发布了一个问题，有关如何使用消息与故障异常之间进行通信服务.
I posted a question about using Messages versus Fault Exceptions to communicate business rules between services.
给我的印象是，将异常抛出到网络上会产生开销，但是考虑到它只是序列化和反序列化的消息，实际上它们是相同的.
I was under the impression it carried overhead to throw this exception over the wire, but considering it's just a message that get serialized and deserialized, they were in fact one and the same.
但是，这让我开始考虑一般抛出异常，或更具体地说，抛出FaultExceptions.
But this got me thinking about throwing exceptions in general or more specifically throwing FaultExceptions.
如果我使用的话，现在在我的服务范围内
Now within my service, if i use
throw new FaultException
传达简单的业务规则，例如您的帐户尚未激活"， 现在这会带来什么开销? 它与在.NET中引发常规异常的开销相同吗?还是WCF服务通过使用故障合同更有效地处理这些问题.
to communicate a simple business rule like "Your account has not been activated", What overhead does this now carry? Is it the same overhead as throwing regular exceptions in .NET? or does WCF service handle these more efficiently with the use of Fault Contracts.
因此在我的用户示例中，这是编写服务方法的最佳/首选方式
So in my user example, which is the optimal/preferred way to write my service method
选项a
public void AuthenticateUser()
{
throw new FaultException("Your account has not been activated");
}
选项b
public AutheticateDto AutheticateUser()
{
return new AutheticateDto() {
Success = false,
Message = "Your account has not been activated"};
}
推荐答案
好吧...一般来说，您不应该为预期的条件或您定期期望发生的任何事情抛出异常.它们比常规方法要慢得多.例如，如果您期望文件打开失败，请不要向调用者抛出该异常，也不要将失败代码传递回去，也不要提供"CanOpenFile"方法来进行测试.
Well... In general you shouldn't be throwing exceptions for expected conditions, or anything you expect to happen regularly. They are massively slower than doing normal methods. E.g., if you expect a file open to fail, don't throw a that exception up to your caller, pass the back a failure code, or provide a "CanOpenFile" method to do the test.
是的，消息文本本身并不多，但是会引发并处理真正的异常(由于IIS可能更昂贵)，然后在反序列化故障时再次在客户端上引发真正的异常.因此，连按两次.
True, the message text itself isn't much, but a real exception is thrown and handled (possibly more expensively because of IIS), and then real exception is again thrown on the client when the fault is deserialized. So, double hit.
老实说，如果通话量很少，那么您可能不会受到任何明显的打击，但是无论如何都不是一个好主意.谁想将业务逻辑放在catch块中:)
Honestly, if it is a low volume of calls, then you probably won't take any noticeable hit, but is not a good idea anyway. Who wants to put business logic in a catch block :)
这篇关于WCF-在服务中引发FaultExceptions的开销的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
