Общий способ обработки исключений

Question

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

Насколько я знаю, в ASP.NET существует три способа отловить исключения.app -

1. В самом коде (try, catch, finally)
2. В событии Page_Error на странице
3. InApplication_Error событие global.asax страницы

Поскольку у меня есть много событий и функций на моих страницах .aspx, я хотел одно единственное место, которое будет ловить и собирать исключения.Другими словами, я действительно не чувствую, как spreaindg try-catch оценивает весь код, поэтому я подумал об использовании события Page_Error (которое я читаю, может быть хорошей практикой в ​​некоторых случаях).

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

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

Answer 1

Используйте Элму - http://code.google.com/p/elmah/

Это позволит отлавливать и регистрировать любые необработанные ошибки без написания строки кода:)

Answer 2

В моем случае я использовал Post Sharp, AOP-фреймворк. Я использовал его, чтобы ввести некоторую политику при возникновении исключения.

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

Так или иначе, решение для перехвата исключения на «абстрактном» (так сказать) уровне без заполнения кода try-catch, вероятно, будет содержать это количество AOP.

Гудлак

Answer 3

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

Взять, к примеру, этот бит кода:

Int32 value = 0; // let's say this was passed in.
double newValue = 5 / value;

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

Answer 4

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

Answer 5

Я считаю, что отсутствие попыток / отлова исключений может ограничить вас от некоторых преимуществ / методов, таких как Повторение функции в C # до тех пор, пока она не перестанет генерировать исключение . В любом случае вы можете разрешить показывать пользовательскую страницу ошибки на web.config , если она подходит.

Я бы лично использовал Application_Error для регистрации этих исключений, но в этом смысле лучше было бы попробовать @MoXplod advice.

Кстати, я могу быть не совсем прав, но запись трассировки стека на страницу при возникновении ошибки может быть связана с проблемой безопасности.

Answer 6

Поскольку произошло исключение, это означает, что страница не может отображаться (по какой-либо причине). Это приведет к тому, что исключение будет распространяться вверх по стеку вызовов, пока оно не будет где-то обработано. Последнее место, где вы можете обработать исключение в ASP.NET, находится в global.asax, и, поскольку возникла проблема, вы можете создать любой вывод, который хотите записать клиенту:

protected void Application_Error(Object sender, EventArgs e)
{
  Response.Write("Really sorry this happened")
}

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

Конечно, вы также можете указать пользовательскую страницу ошибки в файле web.config.