Application.ThreadException VS AppDomain.UnhandledException [英] Application.ThreadException vs AppDomain.UnhandledException

问题描述

一是一些背景：我有一个互操作做给本机DLL一个多线程的WinForms应用程序。此应用程序与未处理的异常有时会崩溃，我们正在努力研究它为什么发生。为了方便吧，我创建一个全球性的异常处理程序，我打算从其生成过程转储文件。

First some background: I have a multi-threaded WinForms application that is doing interop to native dlls. This application crashes sometimes with unhandled exception and we are trying to investigate why does it happen. In order to facilitate it, I am creating a global exception handler and I plan to generate process dumpfile from it.

现在走向未来的问题：截至目前此应用程序处理程序 Application.ThreadException ，但它仍与未处理的崩溃例外。我想增加一个处理程序 AppDomain.UnhandledException 也虽然我不知道，如果它要帮助的。有没有在这种情况下任何可能未处理的异常，将不会被 Application.ThreadException ？

Now coming towards question: as of now this application has handler for Application.ThreadException but it still crashes with unhandled exception. I am thinking of adding a handler for AppDomain.UnhandledException also although I am not sure if its going to help. Are there any possible unhandled exception in this scenario that will not be caught by Application.ThreadException?

推荐答案

是的，Application.ThreadException只能陷阱例外是在UI线程提高。在代码的运行由于Windows的通知。或者在技术方面，事件是由消息循环触发。几乎所有的WinForms事件适合这一类。

Yes, Application.ThreadException can only trap exceptions that are raised in the UI thread. In code that's run due to Windows notifications. Or in technical terms, the events that are triggered by the message loop. Most any Winforms event fit this category.

它做什么的不的陷阱上调在任何非UI线程，就像一个工作线程异常启动与Thread.Start（），ThreadPool.QueueUserWorkItem或委托的BeginInvoke的（）方法。在那些任何未处理的异常将终止应用程序，AppDomain.UnhandledException是奄奄一息。

What it does not trap are exceptions raised on any non-UI thread, like a worker thread started with Thread.Start(), ThreadPool.QueueUserWorkItem or a delegate's BeginInvoke() method. Any unhandled exception in those will terminate the app, AppDomain.UnhandledException is the last gasp.

进一步走向下坡，这在非托管线程母语引发硬件异常代码从未任何管理CLR呼叫不能与任何CLR机制进行检测。一个AccessViolation（异常代码0000005）是死亡的最常见原因。捕获这些的唯一方法是通过Windows API，SetUnhandledExceptionFilter（）。这是很难得到正确。

Going further down-hill, hardware exceptions that are raised in an unmanaged thread by native code that never made any managed CLR call can not be detected with any CLR mechanism. An AccessViolation (exception code 0xc0000005) is the most common cause of death. The only way to trap those is through the Windows API, SetUnhandledExceptionFilter(). This is hard to get right.

您可以用Application.SetUnhandledExceptionMode禁用Application.ThreadException（）。这是一个明智的做法，给用户继续选项不使一个很大的意义。现在，在托管线程的所有异常行为相同，使用AppDomain.UnhandledException登录他们。

You can disable Application.ThreadException with Application.SetUnhandledExceptionMode(). Which is a wise thing to do, giving the user the Continue option doesn't make a lot of sense. Now all exceptions in managed threads behave the same, use AppDomain.UnhandledException to log them.

这篇关于Application.ThreadException VS AppDomain.UnhandledException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！