我已经阅读并讨论了以下问题和文章以及现在和过去的许多其他问题：
Main method code entirely inside try/catch: Is it bad practice?
我将使本文成为组织中异常处理的编码标准！非常好但没有回答我： 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
答案 0 :(得分：4)
好问题！你的一个链接（Daniel Turini）是我的最爱之一。当我的想法需要一些理顺时，我会一次又一次地回到它。
表达我对异常处理的态度的一个好方法是：只有处理例外，你可以处理。这意味着您永远无法确定如何应对任何可能出现的异常，并在您的代码中实现此功能。可以处理一些“预期的”异常 - 但代码对这些异常的响应本身就是一个设计决策。恕我直言，处理这些问题的优先事项不是在应用程序关闭后（或者至少退出它所涉及的特定事务中）留下一团糟 - 不，以便应用程序能够不管怎么说，因为关闭了一个优雅的“我不知道为什么，但是这个例外发生了”通知（对于日志/ IT电子邮件/ MsgBox，无论如何）在某种程度上是一件“坏事”。
与这种设计正好相反的是那种试图使应用成为“核 - 世界末日幸存者”的异常处理。 尝试 ...我已经看到代码通过假设网络文件服务器已关闭来响应IO错误，并分支到尝试以某种不受欢迎的方式工作在C：驱动器上。尝试SELECT FROM ATable的代码：如果表不存在，则创建它！每当有人写这样的代码时，一个婴儿负鼠就会死亡。
图里尼说“永远不会吞下例外”。我正在考虑的是这个的延伸：恕我直言，你必须非常谨慎地让应用程序继续运行，即使是对一个已知的，确定类型的异常，已知原因的回应：因为即使这构成了“吞咽”例外。做到这一点，但要认真做好。
因此，在我的思维方式中，总是存在一个通用的“任何其他情况”异常处理程序的空间，它通过记录发生的事情的详细信息并将其关闭，将决策委托给更高的权力（人类）。应用
我的2c ..
答案 1 :(得分：0)
恕我直言：抓住应用程序最后一层中的每个异常，以防止您的应用程序崩溃，（在UI中，在您的控制台App的正文中，或在某些服务方法的正文中...等）处理它，如果你可以或至少，记录它，但在内部层，只捕获你刚才知道的异常处理它们的异常，并抛出或包装那些没有完美的处理方法，但如果你的代码有层之间没有明确的界限（在我的情况下也一样）你应该尝试在可能发生的情况下处理异常，并尝试以一种构造良好的方式重置（重写）这个应用程序（我们将尽快完成！）！