.net - 为什么 AppDomain 异常总是会终止应用程序？

Question

这与previous question有关.

我现在想了解的是，为什么可以阻止 UI 线程异常终止应用程序，而不能阻止非 UI 异常。

引用 this example .

最重要的是，在这种情况下，我希望能够“静默”终止进程——而不显示询问我是否要发送错误报告的 Windows 对话框。

这是我的 AppDomain UnhandledExceptionHandler:

private static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{            
    try
    {
        // Maybe do some logging here if allowed
    }
    catch
    {
    }

    // then just terminate the application
    Application.Exit();            
}

更新
根据 this answer 中的评论，我想澄清一下，最重要的是，我想了解更多关于使 UI 线程能够通过 Application.ThreadException 尽早捕获未处理异常的机制的信息。机制。以及这种行为是否可以在非 UI 线程上实现。

Answer 1

在 Google 上进行了更多搜索后，我发现了这个非常有趣的解释，该解释与 Jeff Atwood on his blog 描述的问题相同。 .

Hi all, Sorry for the confusion. This behavior is actually the design, though the design can be a little convoluted at times.

The first thing to understand is that the UnhandledException event is not an unhandled exception "handler". Registering for the event, contrary to what the documentation says :-(, does not cause unhandled exceptions to be handled. (Since then they wouldn't be unhandled, but I'll stop with the circular reasoning already...) The UnhandledException event simply notifies you that an exception has gone unhandled, in case you want to try to save state before your thread or application dies. FWIW, I have filed a bug to get the docs fixed.

Just to complicate things, in v1.0 and 1.1, an unhandled exception did not always mean that your application would die. If the unhandled exception occurred on anything other than the main thread or a thread that began its life in unmanaged code, the CLR ate the exception and allowed your app to keep going. This was generally evil, because what would often happen was, for example, that ThreadPool threads would silently die off, one by one, until your application wasn't actually doing any work. Figuring out the cause of this kind of failure was nearly impossible. This may be why Jeff thought it worked before...he just always saw crashes on non-main threads.

In v2.0, an unhandled exception on any thread will take down the application. We've found that it's tremendously easier to debug crashes than it is to debug hangs or the silent-stoppage-of-work problem described above.

BTW, on my 1.1 machine the example from MSDN does have the expected output; it's just that the second line doesn't show up until after you've attached a debugger (or not). In v2 we've flipped things around so that the UnhandledException event fires before the debugger attaches, which seems to be what most people expect.

Jonathan Keljo CLR Exceptions PM Jonathan Keljo on February 18, 2005 10:02 PM

但是，我仍然对 UI 线程如何完成允许您为所有 UI 线程异常拥有一个包罗万象的处理程序的技巧感兴趣。

更多，我对仅为我的应用程序禁用 .NET JIT 调试对话框的方法很感兴趣 (没有 disabling it for the whole machine as seen here)