为什么AppDomain异常总是终止应用程序？ [英] Why do AppDomain exceptions invariably terminate the application?

问题描述

这与上一个问题有关。 / p>

我现在想了解的是如何防止UI线程异常终止应用程序，而非UI异常则不能。

有关参考，请参阅这个例子。

最重要的是，在这种情况下我想要做的是默默地终止进程 - 不显示Windows对话框，询问我是否要发送错误报告。

这是我的AppDomain UnhandledExceptionHandler：

  private static void CurrentDomain_UnhandledException（object sender，UnhandledExceptionEventArgs e）
 {
 try 
 {
 //如果允许，也许做一些日志记录
} 
 catch 
 {
} 
 
 //然后只是终止应用程序
应用程序。出口（）; 
} 
  

更新

此答案中的评论内容'我想澄清一点，最重要的是我想了解更多的机制，使UI线程有一个很早的机会通过 Application.ThreadException 机制。是否可以在非UI线程上实现此类行为。

解决方案

所以，在Google上进行了一些更多的搜索后，我发现这个非常有趣的解释被赋予了 Jeff Atwood博客上描述的相同问题， a>。

嗨所有，
对不起，混乱。这个行为实际上是设计，虽然设计可能有点复杂。

首先要了解的是UnhandledException事件不是未处理的异常处理程序。 注册该事件，与文档说明相反： - （不会导致未处理的异常处理。（从那以后，它们不会被处理，但是我将停止循环推理已经...） UnhandledException事件只是通知你异常已经被处理，以防在线程或应用程序死机之前尝试保存状态FWIW，我已经提交了一个错误文档固定。

只是在v1.0和1.1中复杂化，一个未处理的异常并不总是意味着你的应用程序会死，如果未处理的异常发生在除了主线程或线程之外的其他任何东西都开始在非托管代码中使用，所以CLR使用异常并允许你的应用程序继续运行，这通常是坏的，因为例如ThreadPool线程将静默地一个接一个地死去，直到你的申请实际上没有做任何工作这种失败的原因几乎是不可能的。这可能是为什么Jeff认为它以前工作的原因...他总是在非主线程中看到崩溃。

在v2.0中，任何线程上的未处理的异常将取消应用程序。我们发现调试崩溃比调试挂起或上述静默停止工作问题要容易得多。

BTW，在我的1.1机器的MSDN的示例确实有预期的输出;只是在连接调试器（或不）之后，第二行才会显示。在v2中，我们已经翻转了一切，以便UnhandledException事件在调试器附加之前触发，这似乎是大多数人期望的。

Jonathan Keljo
CLR例外情况PM
Jonathan Keljo于2005年2月18日10:02 PM

然而，我仍然对如何UI线程完成了一个窍门，允许您为所有UI线程异常创建一个全部处理程序。

更重要的是，我对某种方式感兴趣以禁用我的应用程序的.NET JIT调试对话框（不需要禁用整个机器，如下所示）

This is related to a previous question.

What I'm trying to understand now is how come UI thread exceptions can be prevented from terminating the application while non-UI exceptions can't be.

For reference, see this example.

Most importantly, what I would like to be able to do in that case is "silently" terminate the process--without displaying the Windows dialog box that asks whether I'd like to send an error report or not.

This is my 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();            
}

UPDATE
In light of comments in this answer, I'd like to clarify that most importantly I'd like to find out more about the mechanism that enables the UI thread to have an early opportunity to catch unhandled exceptions via the Application.ThreadException mechanism. And whether such behavior could be implemented on a non-UI thread.

解决方案

So, after doing some more searches on Google I found this very interesting explanation that was given to the same problem as described by 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

However, I'm still interested in how the UI thread accomplishes the trick of allow you to have a catch-all handler for all UI thread exceptions.

Even more, I'm very interested in a way to disable the .NET JIT Debugging Dialog for my application only (without disabling it for the whole machine as seen here)

这篇关于为什么AppDomain异常总是终止应用程序？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！