6

我现在和过去已经深入阅读并讨论了以下问题和文章以及许多其他问题和文章：

何时使用 try/catch 块？

主要方法代码完全在 try/catch 中：这是不好的做法吗？

何时使用 Try Catch 块

我将使这篇文章成为我组织中异常处理的编码标准！非常好的一个，但没有回答我： http: //www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET

try catch 块创建干净代码的最佳实践是什么？

Java 或 C# 中异常管理的最佳实践 这里：我不喜欢这种说法 :( 您不应该尝试在每个可能的地方捕获每个异常。

是否应该组合方法中的多个 Try/Catch 块

当我需要决定用 try-catch 语句包含一些代码块时，我遇到了一个问题，我知道应该包含的代码是错误代码，并且我必须检查我可以检查的内容，但是例如：我需要在某个文本文件中写一行，我应该检查文件是否存在，如果我有写权限，我应该检查磁盘上是否有空间，或者磁盘是可写的，如果我检查了空间，如果在我写文件时发生了什么事（其他一些应用程序或线程使用了空间，或者可移动驱动器已被删除？），如果我检查了这些事情并处理了 IOException 和 SecurityException 以及其他潜在的异常，这是一个最佳实践吗？ ，或者我应该只检查而不使用try-catch？

另一个例子：我正在使用EntityFramework访问数据库，访问时可能会联系到数据库，我知道我应该检查连接是否关闭并尝试打开它，但是有很多很多东西可能导致这个语句失败，数据库可能在可移动驱动器上，读取时可能会删除该驱动器，DBMS的服务可能因任何原因停止，不会抛出空间异常，数据库的方案可能会在我尝试执行我的代码后改变****原因，如何防止我的代码失败，我可以检查所有可以检查的内容，然后继续吗？或者我应该使用 try catch 来处理我可以预期的异常，即使我已经检查过它们？

请给我你的答案的参考，而不是一般的答案！

编辑

并确保阅读：http: //msdn.microsoft.com/en-us/library/seyhszts.aspx

4

2 回答 2

4

好问题！您的链接之一（丹尼尔·图里尼）是我的最爱之一。当我的想法需要理顺时，我会一次又一次地回到它。

表达我对异常处理态度的一个好方法是：只处理你能处理的异常。这意味着您永远无法弄清楚如何应对任何可能出现的异常，并在您的代码中实现这一点。有一些“预期的”异常是可以处理的——但是代码对这些异常的响应本身就是一个设计决策。恕我直言，处理这些问题的优先级是不要在应用程序关闭后留下一团糟（或至少退出它所涉及的特定事务） -不是让应用程序无论如何都能够继续，因为关闭带有优雅的“我不知道为什么，但是发生了这个异常”通知（到日志/IT 电子邮件/MsgBox，无论如何）在某种程度上是“

这种设计的直接对立面是试图使应用程序成为一种“核世界末日幸存者”的异常处理。 尝试...我已经看到通过假设网络文件服务器已关闭来响应 IO 错误的代码，并分支到尝试以某种未设计的方式在 C: 驱动器上工作。以及尝试从 ATable 中选择的代码：如果表不存在，则创建它！！！每次有人写这样的代码，一个小负鼠就会死去。

图里尼说“永远不要吞下例外”。我在想的是对此的扩展：恕我直言，您必须非常小心地让应用程序继续运行，即使是在以已知原因响应已知的、确定类型的异常时：因为即使这构成“吞咽”异常. 做它，但要小心和做好。

因此，在我看来，通用的“任何其他情况”异常处理程序总是有空间的，它通过记录发生的事情的详细信息并关闭应用程序来将决定委托给更高的权力（人类）。

我的2c..

于 2012-11-18T13:28:32.893 回答
0

恕我直言：在应用程序的最后一层捕获每个异常，以防止您的应用程序崩溃（在 UI、控制台应用程序的主体或某些服务方法的主体中......等）并在以下情况下处理它您可以或至少记录它，但是在内部层中，仅捕获您刚刚知道的异常以完美处理它们，并抛出或包装那些没有完美处理方式的异常，但是如果您的代码没有明确的界限在层之间（在我的情况下相同），您应该尝试在可能发生的异常情况下处理异常，并尝试以结构良好的方式重置（重写）此应用程序（我们将很快这样做！）！

于 2012-11-18T15:15:23.320 回答