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

Question

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

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

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

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

throw new FaultException

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

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

вариант а

public void AuthenticateUser()
{
    throw new FaultException("Your account has not been activated");
}

вариант б

public AutheticateDto AutheticateUser()
{
     return new AutheticateDto() { 
          Success = false,
          Message = "Your account has not been activated"};
}

Answer 1

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

Правда, сам текст сообщения невелик, но выдается и обрабатывается реальное исключение (возможно, более дорогое из-за IIS), а затем реальное исключение снова выдается клиенту при десериализации ошибки. Итак, двойной удар.

Честно говоря, если звонков мало, то, вероятно, вы не получите никакого заметного удара, но в любом случае это не очень хорошая идея. Кто хочет поставить бизнес-логику в блоке catch:)

Microsoft: исключения, производительность и альтернативы

Разработчик Fusion: производительность, с примером

Answer 2

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

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