Где поймать исключения

Question

У меня есть WCF svc, разделенный на сервисный уровень, бизнес-логический уровень и уровень доступа к данным.

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

Пожалуйста, не обращайте внимания на любое участие клиента в этом сценарии, я занимаюсь только регистрацией исключений в WCF svc.

Answer 1

Это зависит также от того, как вы строите свое решение. Например, если слои DAL и BLL предназначены для полностью независимых компонентов, то они не могут делать предположений о том, кто их вызывает.Таким образом, они должны оба перехватывать исключения на границе компонента, регистрировать эти исключения, а затем разрешать распространение исключения. Они могут хотеть, чтобы обернуть общее исключение в исключениях послойного конкретно:

catch (Exception ex) 
{ 
    Logger.Log(ex); 
    throw new DalException("Unhandled exception in DAL", ex); 
} 

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

Answer 2

Для этого есть термин - исключение. В основном вам следует запретить исключения SYSTEM для перехода на более высокий уровень, поскольку это может дать атакутору представление о вашей системной архитектуре. WCF Exception Shielding может перехватывать исключения определенного типа и заменять их исключениями другого типа. Например, он может поймать исключение StackOverflow и заменить его своим пользовательским исключением SystemException. При использовании Enterprise Library можно также настроить для регистрации этих исключений, когда они заменяются

Using the Exception Handling Block in Enterprise Library 3.0

Answer 3

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

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

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

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

Answer 4

Обычно я использую общий обработчик ошибок (System.ServiceModel.Dispatcher.IErrorHandler), который привязан к веб-сервисам ServiceBehavior в файле конфигурации.

IErrorHandler.ProvideFault В методе перехватывает исключения выброшенных из службы и:

• Бревно их;

• Passes FaultExceptions через as-is;

• Преобразовывает «бизнес-исключения» (например, нарушения бизнес-правил), выброшенные BLL в FaultExceptions с кодом ошибки «отправитель/клиент»;

• Преобразование технических исключений (например, выбрано DAL) в FaultExceptions с кодом неисправности «приемник/сервер».

Таким образом, сам служебный код содержит только бизнес-код и не требует каких-либо исключений.