Как проверить, выполняется ли код потока в блоке try-catch

Question

Я хотел бы проверить наш код и проверить, работает ли каждый выполняемый нами поток в блоке try catch.

Действительный образец:

Thread loadDataThread = new Thread(new ThreadStart(LoadData));
public void LoadData()
{
   try {/*do something*/}
   catch(Exception ex) { /*Handle exception*/ }
}

Недопустимый образец:

Thread loadDataThread = new Thread(new ThreadStart(LoadData));
public void LoadData()
{
   /* do something */
}

Это можно проверить с помощью FxCop или другого инструмента. Аналогичное правило может быть применено для некоторых других вещей, например. Таймеры и т. Д. ...

Answer 1

См. http://social.msdn.microsoft.com/Forums/en-US/vstscode/thread/a257a910-126e-4c8d-aab3-3199347346ec для примера того, как обнаружить оберточный блок try / catch в правиле FxCop. Что на самом деле немного сложнее сделать, так это определить, какие методы подвержены запуску из фонового потока, поскольку не все они порождаются с помощью очевидных средств запуска, таких как Thread.Start или ThreadPool.QueueUserWorkItem.

Тем не менее, вы, возможно, захотите пересмотреть свой подход с добавления переноса try / catch для использования пользовательских средств запуска потоков, добавляющих try / catch для вас. (Затем можно создать правило FxCop, чтобы убедиться, что вместо аналогов базовой платформы используются настраиваемые средства запуска / помощники.) Это может иметь преимущество, позволяющее систематически применять другие изменения ко всем потокам (например, установка культур, отслеживание запуск трассировки стека для последующего ведения журнала исключений и т. д.) без необходимости изменения всех методов, запускаемых из порожденных потоков.

Answer 2

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

Answer 3

это не отвечает на ваш вопрос напрямую, но, вероятно, уместно.

Заинтересованы ли вы в выполнении вышеизложенного, потому что вы не хотите, чтобы ваше приложение завершало работу / зависало, когда поток генерирует необработанное исключение? Если да, то вы можете добавить следующее в файл app.config в разделе конфигурации:

<runtime>
<legacyUnhandledExceptionPolicy enabled="1"/>
</runtime>

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

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

    void AppStartup()
    {
        AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;
    }

    void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        //log error            
    }

Answer 4

Я не знаю, можете ли вы добавить пользовательское правило для этого в FXCop, но вы можете использовать Mono.Cecil, чтобы сделать это, но это не так просто.