事件的异常处理 [英] Exception handling for events
问题描述
很抱歉这是一个简单的问题（今天我的Google-Fu可能不好）。
I apologize if this is a simple question (my Google-Fu may be bad today).
想象一下这种具有以下设计类型的WinForms应用程序：Main应用程序->显示一个对话框->第一个对话框可以显示另一个对话框。这两个对话框都具有确定 /取消按钮（数据输入）。
Imagine this WinForms application, that has this type of design: Main application -> shows one dialog -> that 1st dialog can show another dialog. Both of the dialogs have OK/Cancel buttons (data entry).
我试图根据Application.ThreadException找出某种类型的全局异常处理。 。我的意思是：
I'm trying to figure out some type of global exception handling, along the lines of Application.ThreadException. What I mean is:
每个对话框都会有一些事件处理程序。第二个对话框可能具有：
Each of the dialogs will have a few event handlers. The 2nd dialog may have:
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
}
}
确实，此对话框中的所有事件处理程序都应以这种方式处理。这是一个特例，因此我只想记录所有相关信息，显示消息并禁用该对话框的确定按钮。
Really, all the event handlers in this dialog should be handled in this way. It's an exceptional-case, so I just want to log all the pertinent information, show a message, and disable the okay button for that dialog.
但是，我想避免在每个事件处理程序中尝试/捕获（如果可以的话）。所有这些尝试/捕获的缺点是：
But, I want to avoid a try/catch in each event handler (if I could). A draw-back of all these try/catch's is this:
private void someFunction()
{
// If an exception occurs in SelectedIndexChanged,
// it doesn't propagate to this function
combobox.selectedIndex = 3;
}
我不认为Application.ThreadException是一个解决方案，因为我不不想让异常一直下降到第一个对话框，然后到主应用程序。我不想关闭该应用程序，我只想对其进行记录，显示一条消息，然后让他们从对话框中取消。他们可以从那里决定要做什么（也许可以在应用程序中的其他地方去做）。
I don't believe that Application.ThreadException is a solution, because I don't want the exception to fall all the way-back to the 1st dialog and then the main app. I don't want to close the app down, I just want to log it, display a message, and let them cancel out of the dialog. They can decide what to do from there (maybe go somewhere else in the app).
基本上，是第一个对话框和第二个对话框之间的全局处理程序（和然后，我想在主应用程序和第一个对话框之间还有另一个全局处理程序。
Basically, a "global handler" in between the 1st dialog and the 2nd (and then, I suppose, another "global handler" in between the main app and the 1st dialog).
推荐答案
是，默认处理Application.ThreadException是一个错误。不幸的是，这是一个必要的错误，不需要立即使成千上万的程序员编写第一个Windows Forms应用程序感到沮丧和沮丧。
Yes, the default handling of Application.ThreadException was a mistake. Unfortunately, it was a necessary mistake, needed to not immediately discourage and despair hundreds of thousands of programmers writing their first Windows Forms application.
您正在考虑的解决方案不是修复，它有很大的潜力使其恶化。尽管用户在异常对话框上单击继续按钮会产生可疑的结果，但是吞噬全局异常处理程序中的异常要糟得多。
The fix you are contemplating is not a fix, it has a lot of potential to make it worse. While a user clicking the Continue button on the exception dialog is a questionable outcome, swallowing exceptions in a global exception handler is much worse.
是，要做为ThreadException编写替换处理程序。让它在消息框中显示e.Exception.ToString（）的值，以便用户知道发生了什么。然后关闭电子邮件或附加到错误日志，以便您知道出了什么问题。然后调用Environment.FailFast（），这样就无法再造成损坏。
Yes, do write a replacement handler for ThreadException. Have it display the value of e.Exception.ToString() in a message box so the user has some idea what blew up. Then fire off an email or append to an error log so you know what went wrong. Then call Environment.FailFast() so no more damage can be done.
对AppDomain.CurrentDomain.UnhandledException做同样的事情。
Do the same for AppDomain.CurrentDomain.UnhandledException. It won't get much of a workout.
使用反馈来改进您的代码。您会发现需要验证的地方。您可以帮助客户的IT员工诊断其LAN和设备的故障。而且，您会发现很少的情况下，您自己的try / catch块可能能够从异常中恢复。
Use the feedback to improve your code. You'll find out where validation is required. You can help the customer's IT staff diagnose trouble with their LAN and equipment. And you'll find the very few cases where your own try/catch blocks might be able to recover from the exception.
这篇关于事件的异常处理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
