WCF - накладные расходы на создание исключений FaultException в вашем сервисе

Question

Я опубликовал вопрос об использовании сообщений и исключений ошибок для обмена бизнес-правилами между службами.

У меня сложилось впечатление, что он несет накладные расходы, чтобы выбросить это исключение по проводам, но, учитывая, что это всего лишь сообщения, которые сериализуются и десериализуются, они фактически были одним и тем же.

Но это заставило меня задуматься о генерации исключений вообще или, более конкретно, об исключениях FaultExceptions.

Теперь в моем сервисе, если я использую

throw new FaultException

для передачи простого бизнес-правила, такого как «Ваша учетная запись не была активирована», Какие накладные расходы это сейчас несет? Это такие же накладные расходы, как и обычные исключения в .NET? или служба WCF обрабатывает их более эффективно с использованием Fault Contracts.

Итак, в моем примере пользователя, который является оптимальным / предпочтительным способом написания моего метода обслуживания

опция

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: исключения и производительность и альтернативы

Developer Fusion: производительность, с примером

Answer 2

Это похоже на обычное исключение и использует тот же код переноса, что и обычное исключение, чтобы привести к ошибке, включая разматывание стека.

Как и исключения, ошибки SOAP, на мой взгляд, должны использоваться не для выполнения программы, а для индикации ошибок.