Как обрабатывать исключения во время жизненного цикла запроса ASP.NET - PullRequest
Новая
       13

Как обрабатывать исключения во время жизненного цикла запроса ASP.NET

0 голосов
/ 27 февраля 2009

Этот вопрос в некотором роде связан с Изящно обрабатывать URI в ASP.NET , поскольку речь идет о том, как наилучшим образом обрабатывать исключения, возникающие в течение жизненного цикла запроса ASP.NET. Я нашел способ обработать большинство исключений изящно, но потом обнаружил, что некоторые исключения возникают так поздно в запросе, что нет способа сделать что-то вроде Server.Transfer для сравнения всей логики представления ошибок на ее собственной странице.

Итак, вместо этого я должен обработать исключение внутри события Application_Error и выполнить Response.Write s и еще много чего. Это ужасно. Я понимаю, что в некоторых случаях поток ответов мог уже быть очищен, поэтому передача запроса на самом деле не вариант. Я хочу спросить, есть ли кто-нибудь, кто нашел элегантное решение этой проблемы?

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

Если уже поздно в жизненном цикле, мне, вероятно, придется сделать Response.Write непосредственно с Application_Error, но если это рано, я могу сделать Server.Transfer. Проблема в том, что попытка сделать Server.Transfer сама по себе вызовет исключение, если она находится в запросе на это.

Итак, существует ли глобальное перечисление или что-то подобное, что будет указывать, слишком поздно делать творческие вещи с ответом или нет?

Ответы [ 3 ]

2 голосов
/ 02 марта 2009

Я использовал этот подход для перехвата всех сгенерированных ошибок, либо в веб-элементах управления, либо на страницах. Все, что от вас требуется, - это наследовать от базового класса (один для страниц и один для пользовательских контролей), каждая страница или пользовательский контроль могут реализовывать свой собственный метод HandleException и делать все, что ему нужно. Полный код здесь:

Прозрачная универсальная обработка исключений для asp.net / MOSS2007 (с кодом)

0 голосов
/ 02 марта 2009

Я предлагаю вам использовать конфигурацию asp.net, чтобы иметь страницу с общей ошибкой для необработанных исключений. Из примера web.config 

    <!--
        The <customErrors> section enables configuration 
        of what to do if/when an unhandled error occurs 
        during the execution of a request. Specifically, 
        it enables developers to configure html error pages 
        to be displayed in place of a error stack trace.

    <customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
        <error statusCode="403" redirect="NoAccess.htm" />
        <error statusCode="404" redirect="FileNotFound.htm" />
    </customErrors>
    -->

В общем обработчике просто зарегистрируйте исключение и позвольте asp.net выполнить перенаправление.

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

0 голосов
/ 27 февраля 2009

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

Вот как.

http://msdn.microsoft.com/en-us/library/ms178713.aspx

Надеюсь, это поможет:

Andrew

...