Каков наилучший способ сбора данных о сбоях?

Question

Таким образом, меня продвигает концепция попыток автоматического сбора данных из программы, т. Е. Появление диалогового окна, в котором пользователю предлагается отправить отчет, если что-то идет не так.

Я работаю в MS Visual Studio C #.

С точки зрения реализации, имеет ли смысл помещать цикл try / catch в мой основной файл program.cs вокруг места запуска приложения? Как это:

        try
        {
            Application.Run(new myMainForm());
        }
        catch (Exception ex)
        {
            //the code to build the report I want to send and to 
            //pop up the Problem Report form and ask the user to send

        }

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

-Adeena

Answer 1

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

Однако вы могли бы также рассмотреть возможность добавления обработчика к событию ThreadException .

Приведенный выше код будет работать, но будут сценарии, в которых многопоточность может быть проблемой с таким кодом, поскольку не весь код в вашей программе Windows Forms будет выполняться в основном потоке цикла Application.Run.

Вот пример кода из связанной статьи:

[STAThread]
static void Main() 
{
   System.Windows.Forms.Application.ThreadException += new ThreadExceptionEventHandler(ReportError);
   System.Windows.Forms.Application.Run(new MainForm());
}

private static void ReportError(object sender, ThreadExceptionEventArgs e)
{
   using (ReportErrorDialog errorDlg = new ReportErrorDialog(e.Exception))
   {
    errorDlg.ShowDialog();
   }
}

Дополнительная документация на MSDN .

Что касается второстепенного момента, использование события ThreadException также позволяет продолжить выполнение основного цикла сообщений в случае, если исключение не является фатальным (т. Е. Сценарии отказоустойчивости), в то время как подход try / catch может потребовать перезапуска основного сообщения. цикл, который может вызвать побочные эффекты.

Answer 2

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

Microsoft затем дает вам логин для загрузки мини-дампов с веб-сайта, которые отправляются, когда пользователь нажимает «Отправить отчет об ошибке».

Хотя люди могут нажимать «Не отправлять», по крайней мере, это диалоговое окно Microsoft, и, возможно, не то, которое вам нужно кодировать самостоятельно. Он будет работать круглосуточно, вам не придется беспокоиться о работоспособности вашего веб-сервера, вы можете отправлять пользователям сведения об обходном пути, а также получать обновления через Центр обновления Windows.

Информация об этой службе находится в статье " Отчеты об ошибках Windows: Начало работы ".

Answer 3

Завершение попытки захвата вокруг всего приложения будет означать, что приложение завершит работу при ошибке.

При использовании метода «попробуй и поймай» каждый метод трудно поддерживать.

Рекомендуется использовать специальные попытки try для блоков кода, которые будут генерировать определенные типы исключений, такие как FormatException, и оставлять общую обработку исключений для обработчиков событий уровня приложения.

try
        {
            //Code that could error here
        }
        catch (FormatException ex)
        {
            //Code to tell user of their error
            //all other errors will be handled 
            //by the global error handler
        }

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

Глобальные обработчики ошибок перехватят все остальное. Вы используете их, подключая обработчики событий к двум событиям System.Windows.Forms.Application.ThreadException ( см. MSDN ) и AppDomain.UnhandledException ( см. MSDN )

Имейте в виду, что исключения "Недостаточно памяти" и StackOverflowException не могут быть обнаружены при перехвате ошибок.

Answer 4

С точки зрения реализации, имеет ли смысл помещать цикл try / catch в мой основной файл program.cs вокруг места запуска приложения?

Конечно и всегда.

Вы должны использовать блоки Try / Catch-Blocks везде, где вы делаете что-то критическое, что может вызвать исключение.

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

Но есть много исключений, которые не должны полностью останавливать приложение, исключения, которые можно просто проглотить, как они ожидаются и не требуют критического завершения приложения. Примером этого являются UnauthorizedAccessExceptions при перемещении или доступе к данным с помощью вашей программы.

Вы должны стараться, чтобы ваши Try / Catch-Blocks были как можно меньше, а также использовать их не слишком много из-за производительности.

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

Answer 5

если вы просто хотите фиксировать сбои, игнорируйте все ошибки и позвольте DrWatson создать для вас мини-дамп. Затем вы можете посмотреть на этот отладчик ina (windbg предпочтительнее для мини-дампов), и он покажет вам строку, в которой произошел сбой вашего кода, а также все параметры, трассировку стека и регистры. Вы можете настроить Drwatson на генерацию полного дампа, в котором вы получите полный дамп памяти ядра для исследования.

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

Отправка минидампа вам - это другое дело, вот статья , вам придется проделать определенную работу, чтобы отправить ее по электронной почте / http / ftp / и т. Д.

Answer 6

Лучший подход - петь для AppDomain.UnhandledException и Application.ThreadException В основной функции вашего приложения. Это позволит вам записывать любые необработанные исключения в вашем приложении. Обтекание в блоке try catch не улавливает все.