事件的异常处理

如果这是一个简单的问题，我深表歉意（我的 Google-Fu 今天可能很糟糕）。

想象一下这个 WinForms 应用程序，它具有这种类型的设计：主应用程序 -> 显示一个对话框 -> 第一个对话框可以显示另一个对话框。两个对话框都有确定/取消按钮（数据输入）。

我试图找出某种类型的全局异常处理，沿着 Application.ThreadException 的思路。我的意思是：

每个对话框都有一些事件处理程序。第二个对话框可能有：

private void ComboBox_SelectedIndexChanged(object sender, EventArgs e)
{
    try
    {      
        AllSelectedIndexChangedCodeInThisFunction();
    }
    catch(Exception ex)
    {
        btnOK.enabled = false;  // Bad things, let's not let them save
        // log stuff, and other good things
    }
}

实际上，该对话框中的所有事件处理程序都应该以这种方式处理。这是一个例外情况，所以我只想记录所有相关信息，显示一条消息，并禁用该对话框的“确定”按钮。

但是，我想避免在每个事件处理程序中尝试/捕获（如果可以的话）。所有这些 try/catch 的缺点是：

private void someFunction()
{
    // If an exception occurs in SelectedIndexChanged,
    // it doesn't propagate to this function
    combobox.selectedIndex = 3; 
}

我不相信 Application.ThreadException 是一个解决方案，因为我不希望异常一直回到第一个对话框，然后回到主应用程序。我不想关闭应用程序，我只想记录它，显示一条消息，然后让它们从对话框中取消。他们可以决定从那里做什么（也许去应用程序中的其他地方）。

基本上，第一个对话框和第二个对话框之间有一个“全局处理程序”（然后，我想，主应用程序和第一个对话框之间有另一个“全局处理程序”）。

是的，Application.ThreadException 的默认处理是一个错误。不幸的是，这是一个必要的错误，需要避免立即阻止和绝望成千上万编写他们的第一个 Windows 窗体应用程序的程序员。

您正在考虑的解决方案并不是解决问题，它很有可能使情况变得更糟。虽然用户单击异常对话框上的“继续”按钮是一个值得怀疑的结果，但在全局异常处理程序中吞下异常则更糟糕。

Yes, do为 ThreadException 编写一个替换处理程序。让它在消息框中显示 e.Exception.ToString() 的值，以便用户了解发生了什么问题。然后发送电子邮件或附加到错误日志中，以便you知道出了什么问题。然后调用Environment.FailFast()，这样就不会造成更多损坏。

对 AppDomain.CurrentDomain.UnhandledException 执行相同的操作。它不会得到太多的锻炼。

使用反馈来改进您的代码。您会发现哪里需要验证。您可以帮助客户的 IT 员工诊断其 LAN 和设备的故障。您会发现在极少数情况下您自己的 try/catch 块可能能够从异常中恢复。