我发布了一个有关使用消息与故障异常在服务之间通信业务规则的问题。

我给人的印象是，将异常抛出到网络上会产生开销，但是考虑到只是序列化和反序列化的消息，它们实际上是相同的。

但这让我开始考虑一般抛出异常，或者更具体地说，抛出FaultExceptions。

现在在我的服务范围内，如果我使用

throw new FaultException

传达诸如"帐户尚未激活"之类的简单业务规则，
现在这会带来什么开销？
它与在.NET中引发常规异常的开销相同吗？还是WCF服务通过使用故障合同更有效地处理这些问题。

因此，在我的用户示例中，这是编写我的服务方法的最佳/首选方式

选项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"};
}

解决方案

这就像一个普通异常，并且使用与普通异常相同的包装代码来封送故障，包括展开堆栈。

我认为，像异常一样，SOAP错误不应用于程序流程，而只能指示错误。

好吧...一般来说，我们不应该为预期的条件或者任何我们希望定期发生的事情抛出异常。它们比常规方法要慢得多。例如，如果我们期望文件打开失败，请不要向调用者抛出该异常，也不要将失败代码传回，或者提供" CanOpenFile"方法进行测试。

的确，消息文本本身并不多，但是会引发并处理真正的异常(由于IIS可能会花费更高的代价)，然后在反序列化故障时再次在客户端上引发真正的异常。因此，双击。

老实说，如果通话量很少，那么我们可能不会受到任何明显的打击，但是无论如何都不是一个好主意。谁想把业务逻辑放在一个陷阱中:)

Microsoft：例外与性能和替代方法

开发人员融合：性能，包含示例