Обработка исключений в ASP.NET Webforms - PullRequest
9 голосов
/ 17 февраля 2009

Какой метод обработки исключений в веб-формах ASP.NET является предпочтительным?

У вас есть метод Page_Error, который вы добавляете (я думаю) на уровне web.config, и весь сайт перенаправляется туда при возникновении ошибки.

Значит ли это, что вы не должны использовать try-catch где-либо в приложении веб-форм? (Предполагая, что вы не хотите скрывать ошибки)

Ответы [ 5 ]

12 голосов
/ 17 февраля 2009

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

4 голосов
/ 17 февраля 2009

В дополнение к предложению Эндрю, убедитесь, что обновили файл web.config, установив для CustomErrors значение «Вкл.», И укажите общую страницу ошибок для перенаправления этих ошибок верхнего уровня. Global_asax по-прежнему будет регистрировать ошибку, и тогда пользователь сможет увидеть дружественную страницу. Это также позволит вам настроить несколько стандартных ошибок типа, таких как 404 и 200, а также многое другое.

2 голосов
/ 14 сентября 2009
  • Веб-приложение обычно состоит из пользовательского интерфейса, уровня доступа к бизнесу и данным. Каждый уровень должен выполнять свою роль в отношении обработки исключений. Каждый уровень должен (для повторного использования кода) проверять состояние ошибки и исключать обтекание (после его регистрации) и может распространяться на вызывающий уровень. Слой пользовательского интерфейса должен скрывать исключение и отображать дружественное сообщение. Поймать все исключения в пользовательском интерфейсе, возможно, не очень хорошая идея. Исключения, если это возможно, должны быть зарегистрированы в базе данных. Это позволит легко обслуживать и исправлять ошибки

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

    string fname = "abc";
    //Always check for condition, like file exists etc...
    if (System.IO.File.Exists(fname))
    {
    
    }
    else
    {
    
    }
    
  • Всегда убедитесь, что вызывается код очистки. Используя утверждение или попробуйте наконец.

  • Вы можете перехватить все исключения в Global.asax (файл приложения asp.net)

    void Application_Error(object sender, EventArgs e) 
    { 
        // Code that runs when an unhandled error occurs
        Exception objErr = Server.GetLastError().GetBaseException();
        string err = "Error Caught in Application_Error event\n" +
           "Error in: " + Request.Url.ToString() +
           "\nError Message:" + objErr.Message.ToString()+ 
           "\nStack Trace:" + objErr.StackTrace.ToString();
        EventLog.WriteEntry("Sample_WebApp",err,EventLogEntryType.Error);
        Server.ClearError();
        //additional actions...
    
    }
    

и добавьте раздел <customerror> в веб-конфигурации, чтобы перенаправить пользователя на отдельную страницу

    <customErrors defaultRedirect="error.htm" mode="On">
    </customErrors>
0 голосов
/ 17 февраля 2009

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

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

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

Вы должны использовать try / catch в тех местах, где вы можете сделать что-то значимое с ошибкой, например, исправить это или использовать другой подход.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...