我应该在 try-catch 语句中包含哪些类型的代码块？ [关闭]答案

【问题标题】：What types of code blocks should I enclose with try-catch statement? [closed]我应该在 try-catch 语句中包含哪些类型的代码块？ [关闭]
【发布时间】：2012-11-06 13:21:47
【问题描述】：

我现在和过去都深入阅读并讨论了以下问题和文章：

When to use try/catch blocks?

Main method code entirely inside try/catch: Is it bad practice?

When to use Try Catch blocks

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

What is the Best practice for try catch blocks to create clean code?

Best practices for exception management in Java or C# 在这里：我不喜欢这种说法 :( 您不应该尝试在每个可能的地方捕获每个异常。

Should multiple Try/Catch blocks in a method be combined

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

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

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

编辑

请务必阅读： http://msdn.microsoft.com/en-us/library/seyhszts.aspx

【问题讨论】：

如果您投了反对票，请发表评论！
您只关心它为什么会失败，如果您可以或愿意在代码中进行纠正它的工作。否则，您可以只记录异常并重新抛出。大多数应用不需要您提议的那种稳健性，有些则需要。

标签： c# .net exception exception-handling try-catch

【解决方案1】：

好问题！您的链接之一 (Daniel Turini) 是我的最爱之一。当我的想法需要理顺时，我会一次又一次地回到它。

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

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

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

因此，在我看来，总有一个通用的“任何其他情况”异常处理程序的空间，它通过记录发生的细节并关闭应用程序。

我的 2c..

【讨论】：

我认为正确的方法应该是确保意外异常使任何可能由于意外偏离正常执行顺序而损坏的数据结构无效。如果代码可以在没有这些数据结构的情况下生存，它应该。如果不能，使数据结构无效将确保它迅速消亡。如果代码调用LoadDocument 并得到一个异常，它不应该知道操作可能无法知道它是否应该崩溃或只是报告无法读取文件的所有可能原因。

【解决方案2】：

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

【讨论】：