Почему я не получаю трассировку исключений на странице перенаправления ошибок?

Question

В своем стремлении реализовать лучшие пользовательские методы обработки ошибок мне пришла в голову идея не использовать try catch где-нибудь в моем коде. Вместо этого я решил использовать customErrors mode = "On" и перенаправить на страницу ошибок и показать подробности исключений на этой странице.

//My test code from which error will come
public ActionResult Index()
    { 
        AAA aa = null;
        aa.a = "a"; 
    }

//My web.config file
 <customErrors mode="On" defaultRedirect="~/Errors/Error.aspx">
  <error statusCode="404" redirect="~/Errors/404.html" />
</customErrors>

//My error handling page(Error.aspx):
 protected void Page_Load(object sender, EventArgs e)
    {
        Exception error;
        error = Server.GetLastError();            
    }

Мне кажется, что я должен получить сообщение об ошибке на своей странице обработки ошибок. Но я всегда получаю ноль.

Как получить сообщение об исключении на странице обработки ошибок?

Answer 1

Позвольте мне пролить некоторый свет на то, как я обычно обрабатываю исключения в проектах, над которыми я работаю. Но давайте разберемся на разделы.

Страницы ошибок

На страницах ошибок не должно отображаться реальное исключение при работе . Пользователю не нужно знать, что в БД произошел сбой, который может подвергнуть вашу систему проблемам безопасности. Страница с общей ошибкой или хорошо документированным кодом ошибки сделает эту работу. Но, конечно, в вашей среде разработки нормально показывать исключения. Я бы предложил использовать customErrors mode="RemoteOnly" в этом случае.

Код ошибки

В зависимости от системы, которую вы разрабатываете, важно иметь код ошибки с сообщением. Например, пользователь может увидеть «Невозможно подключиться (XYZ_1234)» * или «Невозможно подключиться (ABC_9876)» * - то же сообщение, разные коды - и отправить его в службу поддержки , Если у группы поддержки есть документ, соответствующий кодам с реальными исключениями, они смогут отправить надлежащий отчет разработчикам.

Блоки Try / Catch

Try / Catch - ваш лучший друг, когда дело доходит до исключения. Тем более, что это поможет вам настроить исключение при необходимости. У вас может быть ряд пользовательских классов исключений, каждый со своей характеристикой, которые помогут вам узнать проблему еще до отладки. Один простой пример:

public class ExceptionWithCode : Exception
{
    public ExceptionWithCode(string code, string message) : base(message)
    {
        this.Code = code;
    }

    public string Code { get; }
}

В коде вы должны подходить к нему более или менее следующим образом:

try
{
    // Do whatever database operation here
}
catch (SqlException ex)
{
    // Log the exception
    _logService.Log(ex);

    // Throw something else to the user
    throw new ExceptionWithCode("XYZ_1234", "Unable to connect");
}
catch (Exception ex)
{
    // Log the exception
    _logService.Log(ex);

    // Throw something else to the user
    throw new ExceptionWithCode("ABC_9876", "Unable to connect");
}

Обратите внимание, что я использую 2 улова. Во-первых, потому что я знаю, что это исключение может произойти, так как я подключаюсь к БД, во-вторых, может случиться что-то другое. Кроме того, пользователь не знает реального исключения, поскольку он получает случайное исключение с кодом вместо сбоя соединения с БД.

Журналы

Это очень важная часть. Помните: Вы никогда не должны показывать реальные исключения для пользователя. Вместо этого, регистрируйте их в месте, где вы можете легко получить доступ. Это может быть в файле на сервере, в базе данных или даже в журнале событий Windows. Вам не обязательно писать свой собственный инструмент регистрации, вы можете использовать все, что доступно в Интернете. Мой любимый SeriLog , так как я регистрирую большинство моих событий / исключений в текстовых файлах. Но я довольно долго использовал ELMAH с .NET Framework, и это было очень хорошо для журналов в формате XML.

Это работает для меня, потому что:

1. Пользователь информирован о проблеме и может связаться со службой поддержки
2. Я не сообщаю никаким злоумышленникам о недостатках моей системы (по крайней мере, неясно)
3. Я знаю, какое исключение увидел пользователь благодаря коду ошибки, который он мне дал
4. Есть журналы, которые нужно анализировать всякий раз, когда мне нужно