WinForms 中的默认 UnhandledException 策略由什么控制？答案

【问题标题】：What controls the default UnhandledException policy in WinForms?WinForms 中的默认 UnhandledException 策略由什么控制？
【发布时间】：2011-09-04 09:12:35
【问题描述】：

我目前正在维护一个 WinForms 应用程序，它侦听 Application.ThreadException 事件以捕获 GUI 线程上未处理的异常。

直到最近，一切都按预期进行。但是最近，一些生产盒不再适当地提出此事件；当 GUI 线程上出现未处理的异常时，应用程序会跳过处理程序并崩溃。奇怪的是，我能够在我的（新的）开发盒上重现这一点，但实际上有一些机器上的事件是正确引发的。

我可以通过像这样显式设置策略来使行为保持一致：

Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);

但我很想知道是什么控制了默认策略。 MSDN 对“应用程序配置文件”做了模糊的暗示，但在我们的 app.config 或我知道的任何其他配置文件中没有这样的策略设置。

是什么导致了这种不一致的行为？

【问题讨论】：

标签： .net winforms unhandled-exception

【解决方案1】：

我能想到的只有一个。异常处理逻辑知道是否附加了调试器。当默认 UnhandledExceptionMode.Automatic 生效时，这很重要。附加调试器时，Winforms 消息循环不尝试捕获异常。这是相当重要的，它会使调试异常变得相当困难。调试器仅在未处理异常时介入并显示异常助手。

使用 UnhandledExceptionMode.CatchException 没问题，它使异常处理保持一致。换句话说，它在您的开发机器上的行为与在您的客户端机器上的行为完全相同。但是您现在需要 Debug + Exceptions, Throw 框来对代码进行故障排除。这总是让调试器在抛出异常时停止，不管它是否被捕获。

【讨论】：

+1 谢谢。但是什么会导致不同客户端机器之间的行为不一致呢？它们都在运行发布版本。
不要低估用户在该对话框中单击继续而不告诉您的意愿。这很少有好的结局。
我们会在事件引发时显示一个对话框，但无论如何都会记录下来；用户没有发言权。顺便说一句，您在这里的相关答案为我节省了很多麻烦。 social.msdn.microsoft.com/Forums/en-US/winforms/thread/…
我认为我所观察到的与此有关：stackoverflow.com/questions/2876748/…。太奇妙了; 三个你的不同答案帮助了我。

【解决方案2】：

我也开始体验了。我们试图调试我们的测试人员看到并且无法在我们自己的机器上重现的异常。我在 VS 和 viola 中打开了异常停止行为，异常实际上正在发生。但是，如果我要 F11 继续，我会看到异常被默默地忽略了。

我有两台机器。一台机器是Win 7 64位，安装了VS 2008和VS 2010，所以安装了.Net 4.0。我们正在测试的应用程序是 .Net 3.5，并在 VS 2008 中调试。

另一台机器是Win XP 32位，plain jane VS 2008和.Net 3.5。

Win 7 机器默默地忽略。 XP机器大声抱怨。我认为安装 .Net 4.0 会改变一些默认策略。

我已经通过调用来解决它

Application.SetUnhandledExceptionMode( UnhandledExceptionMode.CatchException );

【讨论】：