Я опубликовал вопрос об использовании сообщений и исключений сбоев для обмена бизнес-правилами между службами.
У меня создалось впечатление, что бросать это исключение по сети - это накладные расходы, но, учитывая, что это всего лишь сериализованное и десериализованное сообщение, на самом деле они были одним и тем же.
Но это заставило меня задуматься о генерации исключений в целом или, более конкретно, о создании исключений FaultExceptions.
Теперь в моих услугах, если я использую
throw new FaultException
сообщить простое бизнес-правило, например «Ваша учетная запись не активирована», Какие накладные расходы это теперь несет? Это те же накладные расходы, что и создание обычных исключений в .NET? или служба WCF справляется с этим более эффективно с помощью контрактов о сбоях.
Итак, в моем примере с пользователем, это оптимальный / предпочтительный способ написать мой метод обслуживания
вариант а
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"};
}





Это похоже на обычное исключение и использует тот же код упаковки, что и обычное исключение, для маршалинга в ошибку, включая раскручивание стека.
Как и исключения, ошибки SOAP, на мой взгляд, не должны использоваться для выполнения программы, а должны указывать на ошибки.
Что ж ... В общем, вы не должны выбрасывать исключения для ожидаемых условий или чего-то, что вы ожидать должно происходить регулярно. Они намного медленнее, чем обычные методы. Например, если вы ожидаете, что при открытии файла произойдет сбой, не передавайте это исключение вызывающей стороне, передавайте обратно код ошибки или предоставляйте метод «CanOpenFile» для выполнения теста.
Правда, сам текст сообщения невелик, но генерируется и обрабатывается реальное исключение (возможно, более дорого из-за IIS), а затем реальное исключение снова генерируется на клиенте при десериализации ошибки. Итак, двойной удар.
Честно говоря, при небольшом количестве звонков вы, вероятно, не получите заметного удара, но в любом случае это не лучшая идея. Кто хочет поместить бизнес-логику в блок catch :)