问Windows窗体应用程序中异常处理的最佳实践？

EN

再多一点..。

您绝对应该有一个集中的异常处理策略。这可以像在try/catch中包装Main()一样简单，失败很快，并向用户显示一条优雅的错误消息。这是“最后的”异常处理程序。

如果可行，先发制人的检查总是正确的，但并非总是完美的。例如，在您检查文件是否存在的代码和您打开它的下一行之间，该文件可能已被删除或某些其他问题可能会阻碍您的访问。在那个世界里，你仍然需要try/catch/finally。根据需要使用抢占式检查和try/catch/finally。

永远不要“吞下”一个异常，除非在记录最充分的情况下，你绝对、肯定地确定抛出的异常是适合居住的。这种情况几乎永远不会发生。(如果是，请确保只接受特定的异常类--千万不要接受System.Exception。)

在构建库(供应用程序使用)时，不要吞下异常，也不要害怕让异常冒泡出来。除非你有有用的东西要添加，否则不要重新抛出。永远不要(在C#中)执行以下操作：

throw ex;

因为您将擦除调用堆栈。如果必须重新抛出(这有时是必要的，例如在使用Enterprise Library的异常处理块时)，请使用以下方法：

throw;

归根结底，运行中的应用程序抛出的绝大多数异常都应该在某个地方公开。它们不应该向最终用户公开(因为它们通常包含专有或其他有价值的数据)，而应该通常记录下来，并将异常通知给管理员。为了简单起见，可以向用户呈现一个通用的对话框，可能带有一个参考号。

.NET中的异常处理与其说是科学，不如说是艺术。每个人都会在这里分享他们最喜欢的东西。这些只是我从第一天开始使用.NET时学到的一些技巧，这些技巧不止一次挽救了我的性命。您的里程可能会有所不同。

有一个很棒的代码CodeProject article here。以下是几个亮点：

• 做好最坏的打算*
• 及早检查
• 不信任外部数据异常唯一可靠的设备是:视频、鼠标和keyboard.
• Writes可能出现故障，太安全了<

>H213

• 不要抛出新的异常信息将重要的异常信息放在消息字段
• 为每个thread
• Generic

exception ()；切勿在每个线程中只记录一次Exception.Message!

• Don't捕获(异常)不要吞咽exceptions
• Cleanup代码应放入最终块中使用"using“everywhere
• Don't return special values on error conditions
• Don't resource
• Don't exceptions ignored
• Don't
• exceptions

ignored

• Don‘t
• exception处理作为从方法返回信息的手段使用exception

error不应为ignored

• Don’t的错误清除堆栈跟踪重新引发时清除堆栈跟踪在不添加语义value
• Exceptions的情况下更改异常的exception
• Avoid应标记为可疑的Serializable
• When。不要断言，抛出Exception
• Each异常类应该至少有三个原始constructors
• Be在使用AppDomain.UnhandledException event
• 时要小心不要重复发明轮子
• 不要使用非结构化错误处理(VB.Net)

请注意，Windows窗体有自己的异常处理机制。如果单击窗体中的某个按钮，并且该按钮的处理程序引发了处理程序中未捕获的异常，则Windows窗体将显示其自己的未处理异常对话框。

要防止显示未处理的异常对话框，并捕获此类异常以便记录和/或提供您自己的错误对话框，您可以在调用Application.ThreadException ()方法中的Application.Run()之前附加到Main事件。