Лучшая практика для обработки ошибок службы WCF?

Question

Я кодирую какой-то сервис WCF.большинство исключений попадают в реализацию BL и обрабатываются там.Каждый из типов возвращаемых данных моего API - это класс (с именем - "result"), содержащий код ошибки, сообщение об ошибке и логическое значение успеха.

Когда обрабатываются исключения, этот класс соответствующим образом обновляется и в конце отправляется обратно вклиент.Некоторые исключения отклоняются от курса, не обрабатываются.В настоящее время я обертываю каждый из моих вызовов BL из сервисного уровня с помощью универсального try-catch, чтобы я мог перехватить каждое необработанное исключение и создать общий класс «result» с общим сообщением об ошибке, кодом ошибки и success = false.

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

Answer 1

Проверить экранирование исключений.

Это процесс, в котором исключения, вызываемые службой, сопоставляются с договорами о сбоях в соответствии с правилами, указанными в файле конфигурации.Это экономит много работы осла с блоками try / catch.

Вот одна запись , чтобы помочь вам:

В общем, ошибки - делятся на 3 категории:

1) Ошибка клиента - клиент попытался сделать что-то недопустимое, поэтому он должен знать об этом.Например, не удалось установить обязательное поле.- Вернуть конкретное сообщение с объяснением ошибки.

2) Бизнес-ошибка, которая не влияет на клиента.Ошибка, которая считается нормальной работой, например, ошибка проверки авторизации платежа.Либо полностью скрыть от клиента, либо вернуть какое-либо сообщение: «Ошибка выполнения запроса: повторите попытку позже ...»

3) Системная ошибка - неожиданно - не нормальная работа: замените общим сообщением: «Системная ошибка:Позвоните в службу поддержки "

Во всех случаях, однако, главное, чтобы вы удалили трассировку стека, особенно если это общедоступная служба.

При экранировании у вас будет 3 контракта на отказ, охватывающих вышеуказанные сценариии установите соответствующий текст в конфигурации Экранирование.

Имейте в виду, что обычно вы хотите отключить экранирование во время разработки, так как отладка системы - правильная задача!

Answer 2

Я отличаюсь от других.Я думаю, что таким же образом методы HTTP GET, POST, PUT, DELETE, таким образом, поддерживают операции CRUD, коды ответов HTTP 200, 500 и т. Д., Поддерживают успех / неудачу, и это, на мой взгляд, целесообразно для использования.Результат 500 по-прежнему имеет тело ответа HTTP, и такое тело полностью читаемо (если IIS не выдает HTML; у вас есть контроль над этим).Между тем, реализации протокола XML, такие как Microsoft SOAP из WCF, уже обертывают исключения ошибочным протоколом.

Если вы собираетесь генерировать исключения, генерируйте их.При этом просто документируйте их, чтобы потребители могли планировать соответственно.

Answer 3

Если вы пропустите необработанные исключения из службы WCF, это может привести к нежелательным последствиям, таким как нахождение канала связи в состоянии сбоя, когда в сценарии сеанса клиент больше не может использовать тот же экземпляр прокси-сервера клиента, но вынужден создать новый один и начать новый сеанс. В целом, я думаю, что хорошо иметь контроль над ошибками, которые появляются в вашей службе WCF, и предоставлять клиентам полезную информацию. Взгляните на IErrorHandler . Этот интерфейс дает вам контроль над сгенерированным отказом SOAP, необработанными исключениями, а также позволяет выполнять дополнительные задачи, такие как ведение журнала, и позволяет вам решить, хотите ли вы сохранить сеанс или нет в нем. случай сессионной привязки. Вы добавляете свой собственный обработчик ошибок с помощью расширяемости WCF, такой как служба, конечная точка, контракт, поведение операций.

Обратите внимание, что IErrorHandler вызывается перед отправкой ответного сообщения. Таким образом, существует вероятность возникновения необработанного исключения в стеке канала во время сериализации, кодирования и т. Д.

Answer 4

Лично я бы не выставлял необработанные исключения и не передавал их клиенту. Я бы определил те исключения, которые могут заинтересовать клиента, и распространять их только. Исключения, не связанные напрямую с тем, что хотят делать клиенты (ArgumentException может указывать причину «CustomerId не может быть больше 20 символов» и т. Д.), С которой я буду иметь дело в службе и только указать, что на сервере произошла какая-то внутренняя ошибка сервера. сервисная сторона, которая прервала выполнение и означала, что операция, которую пытался выполнить клиент, не была завершена. Это я бы сделал, потому что клиент не может предпринять какие-либо действия из-за внутренних ошибок сервера. Они могут исправить свои параметры в случае возникновения ArgumentException путем повторной проверки параметров и повторения операции.

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

Answer 5

Я думаю, что оба подхода жизнеспособны.

Лично я предпочитаю не выбрасывать исключения поверх WCF, чтобы клиент мог легко отличить ошибку при обработке на стороне сервера от проблемы подключения / протокола: в первом случае ответ будет указывать на сбой, а во втором случае исключение будет быть брошенным.