为什么尝试{...}最后{...}好; 尝试{...} catch {}不好？
我曾经看到有人说，使用catch没有任何争论是不好的形式，特别是如果这种catch没有做任何事情：
StreamReader reader=new StreamReader("myfile.txt");
try
{
int i = 5 / 0;
}
catch // No args, so it will catch any exception
{}
reader.Close();
但是，这被认为是很好的形式：
StreamReader reader=new StreamReader("myfile.txt");
try
{
int i = 5 / 0;
}
finally // Will execute despite any exception
{
reader.Close();
}
据我所知，将清理代码放入finally块并在try..catch块之后放置清理代码的唯一区别在于，如果在try块中有返回语句（在这种情况下，最终的清理代码将会运行，但try..catch之后的代码不会）。
否则，最后有什么特别的？
最大的区别是try...catch会吞噬异常，隐藏发生错误的事实。 try..finally会运行你的清理代码，然后异常会继续，要处理的东西，知道如何处理它。
“最后”是“你必须始终做的事情，以确保程序状态是理智的”。 因此，如果有任何异常可能抛出程序状态的可能性，那么拥有它总是一种很好的形式。 编译器还会竭尽全力确保您的Finally代码得以运行。
“Catch”是“我可以从这个异常中恢复”的陈述。 你只能从你真正可以纠正的例外中恢复过来 - 没有争论就说“嘿，我可以从任何事情中恢复过来”，这几乎总是不真实的。
如果有可能从每个异常中恢复过来，那么它真的会成为一个语义上的狡猾，关于你宣称你的意图是什么。 然而，事实并非如此，几乎可以肯定的是，高于你的帧将会更好地处理某些例外情况。 因此，最后使用，让你的清理代码免费运行，但仍然让更多知识渊博的处理程序处理这个问题。
因为当那一行代码抛出一个异常时，你不会知道它。
使用第一块代码，异常将被简单地吸收 ，即使程序状态可能错误，程序也会继续执行。
随着第二块，异常将被抛出并冒泡，但reader.Close()仍然保证运行。
如果没有预料到异常，那么不要放一个try..catch块，以后在程序进入不良状态时很难再调试，也不知道为什么。
链接地址: http://www.djcxy.com/p/12801.html上一篇: Why is try {...} finally {...} good; try {...} catch{} bad?