Где ловить исключения - PullRequest
4 голосов
/ 23 июня 2010

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

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

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

Ответы [ 4 ]

4 голосов
/ 23 июня 2010

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

Использование блока обработки исключений в Enterprise Library 3.0

3 голосов
/ 23 июня 2010

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

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

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

3 голосов
/ 23 июня 2010

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

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

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

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

1 голос
/ 23 июня 2010

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

Метод IErrorHandler.ProvideFault перехватывает исключения, генерируемые службой, и:

  • Регистрирует их;

  • Пропускает исключения FaultException как есть;

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

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

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

...