".NET 1.1 中未处理的异常处理程序"

Question

我正在维护一个 .NET 1.1 应用程序，我的任务之一是确保用户看不到任何不友好的错误通知。

我已经向Application.ThreadException<\/code>和AppDomain.CurrentDomain.UnhandledException<\/code>添加了处理程序，它们确实被调用了。 我的问题是仍然显示标准 CLR 错误对话框（在调用异常处理程序之前）。

Jeff 在他的博客here<\/a>和here<\/a>上谈到了这个问题。 但是没有解决办法。 那么.NET 1.1 中处理未捕获异常和显示友好对话框的标准方法是什么？

Jeff 的回答被标记为正确答案，因为他提供的链接包含有关如何执行所需操作的最完整信息。

Answer 1

哦，在 Windows 窗体中，您绝对应该能够让它工作。 您唯一需要注意的是在不同线程上发生的事情。

我在这里有一篇旧的代码项目文章应该会有所帮助：

用户友好的异常处理

Answer 2

.NET 1.x Windows 窗体应用程序中未处理的异常行为取决于：

• 抛出异常的线程类型
• 是否发生在窗口消息处理过程中
• 调试器是否附加到进程
• DbgJitDebugLaunchSetting 注册表设置
• App.Config 中的 jitDebugging 标志
• 是否覆盖了 Windows 窗体异常处理程序
• 是否处理了 CLR 的异常事件
• 月相

未处理异常的默认行为是：

• 如果在泵送窗口消息时在主线程上发生异常，它会被 Windows 窗体异常处理程序拦截。
• 如果在泵送窗口消息时主线程上发生异常，它将终止应用进程，除非它被 Windows 窗体异常处理程序拦截。
• 如果异常发生在手动、线程池或终结器线程上，则它会被 CLR 吞下。

未处理异常的联系点是：

• Windows 窗体异常处理程序。
• JIT 调试注册表开关 DbgJitDebugLaunchSetting。
• CLR 未处理的异常事件。

默认情况下，Windows 窗体内置异常处理执行以下操作：

• 在以下情况下捕获未处理的异常：
  • 异常发生在主线程上，并且没有附加调试器。
  • 窗口消息处理期间发生异常。
  • App.Config 中的 jitDebugging = false。
• 向用户显示对话框并防止应用程序终止。

您可以通过设置jitDebugging = true来禁用后者行为App.Config 。 但请记住，这可能是您停止应用终止的最后机会。 因此，捕获未处理异常的下一步是注册事件 Application.ThreadException，例如：

Application.ThreadException += new
Threading.ThreadExceptionHandler(CatchFormsExceptions);

请注意 HKEY_LOCAL_MACHINE\\Software.NetFramework 下的注册表设置 DbgJitDebugLaunchSetting。 这具有我所知道的三个值之一：

• 0：显示用户对话框询问“调试或终止”。
• 1：让异常通过CLR来处理。
• 2：启动在 DbgManagedDebugger 注册表项中指定的调试器。

在 Visual Studio 中，转到菜单Tools → Options → Debugging → JIT将此键设置为 0 或 2。但值 1 在最终用户的机器上通常是最好的。 请注意，此注册表项在 CLR 未处理异常事件之前执行。

最后一个事件是您记录未处理异常的最后机会。 它在您的 finally 块执行之前触发。 您可以按如下方式拦截此事件：

AppDomain.CurrentDomain.UnhandledException += new
System.UnhandledExceptionEventHandler(CatchClrExceptions);

Answer 3

AppDomain.UnhandledException是一个事件，而不是全局异常处理程序。 这意味着，当它被启动时，您的应用程序已经在消耗殆尽，除了清理和错误日志之外，您无能为力。

幕后发生的事情是这样的：框架检测到异常，沿着调用堆栈向上走，发现没有可以从错误中恢复的处理程序，因此无法确定继续执行是否安全。 因此，它启动了关闭序列并启动了此事件，作为对您的礼貌，这样您就可以向已经注定的进程表示敬意。 当在主线程中未处理异常时会发生这种情况。

这种错误没有单点解决方案。 您需要在发生此错误的所有位置的上游放置一个真正的异常处理程序（一个 catch 块），并将其转发到（例如）一个全局处理程序方法/类，该方法将根据以下情况确定简单地报告并继续是否安全异常类型和/或内容。

编辑：可以禁用 (=hack) Windows 内置的错误报告机制，因此当您的应用程序关闭时，不会显示强制的“崩溃和烧毁”对话框。 但是，这对系统中的所有应用程序都有效，而不仅仅是您自己的应用程序。

Answer 4

这是控制台应用程序还是 Windows 窗体应用程序？ 如果它是 .NET 1.1 控制台应用程序，遗憾的是，这是设计使然——MSFT 开发人员在您引用的第二篇博文中证实了这一点：

顺便说一句，在我的 1.1 机器上，来自 MSDN 的示例确实有预期的输出； 只是在您附加了调试器（或不附加）之后，第二行才会出现。 在 v2 中，我们改变了一些事情，以便在调试器附加之前触发 UnhandledException 事件，这似乎是大多数人所期望的。

听起来 .NET 2.0 在这方面做得更好（谢天谢地），但老实说，我从来没有时间回去检查。

Answer 5

它是一个 Windows 窗体应用程序。 Application.ThreadException 捕获的异常工作正常，我没有得到丑陋的 .NET 异常框（可以终止，取消调试？谁想出了那个？？）。

我收到了一些没有被它捕获的异常，最终转到了导致问题的 AppDomain.UnhandledException 事件。 我想我已经捕获了大部分异常，现在我将它们显示在我们漂亮的错误框中。

所以我只希望没有其他一些情况会导致 Application.ThreadException 处理程序无法捕获异常。

Answer 6

简短的回答，<\/strong>看起来，Form.Load 中发生的异常在没有附加调试器的情况下不会路由到 Application.ThreadException 或 AppDomain.CurrentDomain.UnhandledException。<\/em>

更准确的答案\/故事<\/strong>这就是我解决类似问题的方法。 我不能确定它是如何做到的，但这是我的想法。 欢迎提出改进建议。

三个事件，

1. AppDomain.CurrentDomain.FirstChanceException<\/li>
2. AppDomain.CurrentDomain.UnhandledException<\/li>
3. 和 Application.ThreadException<\/li><\/ol>

   累积捕获大多数异常，但不在全局范围内（如前所述）。 在我的一个应用程序中，我结合使用这些来捕获各种异常，甚至是非托管代码异常，如 DirectX 异常（通过 SharpDX）。 所有异常，无论是否被捕获，似乎都在毫无疑问地调用 FirstChanceException。

   处理程序看起来像
   像 DirectX 异常这样的非托管代码异常只出现在 FirstChanceException 中，我必须自己决定异常是否致命。 然后我使用 MyUnhandledExceptionHandler 进行记录，并以友好的方式让用户知道一切都在“控制之下”。
   重要的提示！<\/strong> 该方案仍然没有捕获一种异常。 它确实出现在 FirstChanceException 中，但很难将它与其他类型的异常处理此处理程序区分开来。 在 Form.Load 中直接发生的任何异常都有这种不同的行为。 当附加 VS 调试器时，这些被路由到 UnhandledException 事件。 但是如果没有调试器，则会弹出一条老式的 windows 消息，显示发生的异常的堆栈跟踪。 最烦人的是，它并没有让MyUnhandledExceptionHandlerr一旦完成就被踢，并且应用程序继续在异常状态下工作。 我所做的最终解决方案是使用MyForm.Load += (s,e) => new Thread(()=>{\/* My Form_Load code*\/ }).Start();<\/code>将所有代码从 Form_load 移动到另一个线程MyForm.Load += (s,e) => new Thread(()=>{\/* My Form_Load code*\/ }).Start();<\/code>  . 这样，Application.ThreadException 被触发，它被路由到 MyUnhandledExceptionHandler，我的安全出口。