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

Question

我目前正在编写我的第一个 Windows 窗体应用程序。我现在已经阅读了几本 C# 书籍，因此我对 C# 必须处理异常的语言功能有了相对较好的理解。然而，它们都非常理论化，所以我还没有了解如何在我的应用程序中将基本概念转化为良好的异常处理模型。

有人愿意分享关于这个主题的任何智慧明珠吗？发布您见过像我这样的新手所犯的任何常见错误，以及关于以一种使我的应用程序更加稳定和健壮的方式处理异常的任何一般建议。

我目前正在努力解决的主要问题是:

• 什么时候应该重新抛出异常？
• 我应该尝试拥有某种中央错误处理机制吗？
• 与先发制人地测试诸如磁盘上的文件是否存在之类的事情相比，处理可能抛出的异常是否会影响性能？
• 是否应将所有可执行代码包含在 try-catch-finally block 中？
• 是否存在可以接受空 catch block 的情况？

感谢收到所有建议!

Answer 1

还有一些……

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

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

永远不要“吞下”异常，除非在最有据可查的情况下，当您绝对肯定地确定抛出的异常是可行的。这几乎永远不会是这种情况。 (如果是，请确保您只吞下特定异常类——永远不要吞下System.Exception。)

构建库(由您的应用程序使用)时，不要吞下异常，也不要害怕让异常冒出来。除非你有一些有用的东西要添加，否则不要重新抛出。永远不要(在 C# 中)这样做:

throw ex;

因为您将删除调用堆栈。如果必须重新抛出(偶尔需要，比如使用Enterprise Library的Exception Handling Block时)，使用如下:

throw;

归根结底，运行中的应用程序抛出的绝大多数异常都应该暴露在某个地方。它们不应该暴露给最终用户(因为它们通常包含专有或其他有值(value)的数据)，而是通常记录下来，并通知管理员异常情况。可以向用户显示一个通用对话框，可能带有一个引用编号，以保持简单。

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