Question

我发布了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"};
}

Answer 1

嗯......总的来说，你不应该为预期的条件或你经常发生的任何事情抛出异常。它们比正常方法慢得多。例如，如果您希望文件打开失败，请不要向调用者抛出该异常，向后传递失败代码，或者提供“CanOpenFile”方法来进行测试。

是的，消息文本本身并不多，但抛出并处理了一个真正的异常（可能因为IIS而更昂贵），然后在反序列化故障时再次抛出真正的异常。所以，双击。

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

Microsoft : Exceptions And Performance, & Alternatives

Developer Fusion: Performance, with example

Answer 2

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

与异常一样，在我看来，SOAP故障不应该用于程序流程，而应该用于指示错误。

WCF - 在服务中抛出FaultExceptions的开销

2 个答案: