我发布了一个question关于使用消息与故障异常在服务之间传达业务规则。
我的印象是通过网络抛出这个异常会带来开销，但考虑到它只是一条被序列化和反序列化的消息，它们实际上是一样的。
但这让我开始考虑抛出一般异常或更具体地抛出 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"};
}
请您参考如下方法:
嗯...一般来说，您不应该针对预期条件或您期望经常发生的任何事情抛出异常。它们比执行常规方法慢得多。例如，如果您预计文件打开会失败，请不要向调用者抛出该异常、将失败代码传回或提供“CanOpenFile”方法来进行测试。
是的，消息文本本身并不多，但是抛出并处理了一个真正的异常(可能由于 IIS 的缘故，成本更高)，然后在反序列化故障时再次在客户端上抛出真正的异常。所以， double 。
老实说，如果通话量很小，那么您可能不会受到任何明显的影响，但这无论如何都不是一个好主意。谁想将业务逻辑放在 catch block 中:)
