Обработка исключений в трехуровневом приложении Asp.Net

Question

1) Насколько я понимаю, в three-tier приложении Asp.Net мы должны реализовать обработку исключений следующим образом:

a - мы должны поместить блок try-catch вокруг блока кода (находится влюбой из трех уровней), с которого мы ожидаем, что страница будет корректно восстановлена ​​(когда этот код генерирует исключение)?

b - мы не должны помещать блоки try-catch вокруг кода (расположенного в любом изтри слоя), от которых мы не ожидаем, что страница будет изящно восстановлена.Вместо этого приложение Asp.Net должно всегда управлять этими необработанными исключениями через глобальный обработчик исключений (Application_Error/Page_Error)?

2) Является ли главное преимущество управления необработанными исключениями через Ap plication_Error/Page_Error тем фактом, что таким образом мы централизуемобработка ошибок в одном месте?

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

спасибо

Answer 1

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

Если исключениеслучается, и вы можете восстановиться после него, отлично!

Если возникает исключение, и вы не можете восстановиться после него, тогда важно, чтобы сведения об исключении были зарегистрированы и разработчики были уведомлены об исключении.Как правило, это достигается путем распространения исключения на уровень времени выполнения ASP.NET, чтобы сработало событие ASP.NET Error.Рекомендуется каким-либо образом подписаться на это событие Error, чтобы регистрировать подробности об ошибках и уведомлять разработчиков.Одним из таких инструментов для регистрации и уведомления в случае возникновения ошибки является ELMAH , другим является библиотека ASP.NET Health Monitoring .

Кроме того, если можно,Я бы предложил эту статью, в которой более подробно и подробно изложены замечания, которые я здесь изложил: Рекомендации по обработке исключений для веб-приложений ASP.NET .

Счастливое программирование!

Answer 2

Не обязательно.

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

1b - уровень данных и бизнес-уровень могут не вызываться через веб-сайт, поэтому определенная веб-страница не обязательно актуальна Например, веб-сервис или приложение WPF также могут использовать эти слои.

2 - да, главное преимущество - это единое местоположение для обработки ошибок на сайте.

Answer 3

1а) правильно. 1б) является своего рода правильным; вы можете позволить исключению подняться в стек от вашей модели / бизнес-уровня к презентации и отобразить сообщение об ошибке. Это не должно идти полностью к Application_Error; Page_Error может быть хорошим, но некоторые исключения могут быть (относительно) достаточно распространенными, так что, хотя вы не можете корректно восстановиться, у вас должны быть определенные сообщения об ошибках, связанные с ними в некоторых контекстах.

2) в основном; а также как «поймать все» для исключений, которые вы не смогли предсказать и поймать в более конкретных местах.