我见过有人说，使用不带参数的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块中有返回语句(在这种情况下，finally中的清理代码将运行，但try. catch块之后的代码将不会运行)。
否则，最后有什么特别的?
当前回答
如果您不知道要捕获什么异常类型或如何处理它，那么使用catch语句是没有意义的。你应该把它留给上级，他们可能对情况有更多的了解，知道该怎么做。
在那里仍然应该有一个finally语句，以防出现异常，这样就可以在异常抛出给调用者之前清理资源。
其他回答
finally块仍然会抛出任何引发的异常。最后要做的就是确保在抛出异常之前运行清理代码。
The try..catch with an empty catch will completely consume any exception and hide the fact that it happened. The reader will be closed, but there's no telling if the correct thing happened. What if your intent was to write i to the file? In this case, you won't make it to that part of the code and myfile.txt will be empty. Do all of the downstream methods handle this properly? When you see the empty file, will you be able to correctly guess that it's empty because an exception was thrown? Better to throw the exception and let it be known that you're doing something wrong.
另一个原因是这样做的try. catch是完全错误的。你这样做的意思是，“无论发生什么，我都能处理好。”StackOverflowException呢，你能在那之后清理吗?OutOfMemoryException呢?一般来说，您应该只处理您期望并知道如何处理的异常。
最大的区别是尝试…Catch将吞下异常，隐藏发生错误的事实。Try .finally将运行您的清理代码，然后异常将继续运行，由知道如何处理它的程序来处理。
添加catch子句只是为了重新抛出异常，这是一种糟糕的实践。
摄自:这里
引发和捕获异常不应该作为方法成功执行的一部分常规发生。在开发类库时，必须让客户端代码有机会在执行可能引发异常的操作之前测试错误条件。例如，System.IO.FileStream提供了一个CanRead属性，可以在调用Read方法之前进行检查，以防止引发潜在的异常，如下所示的代码片段:
Dim str As Stream = GetStream() If (str.CanRead) Then '代码来读取流 如果
The decision of whether to check the state of an object prior to invoking a particular method that may raise an exception depends on the expected state of the object. If a FileStream object is created using a file path that should exist and a constructor that should return a file in read mode, checking the CanRead property is not necessary; the inability to read the FileStream would be a violation of the expected behavior of the method calls made, and an exception should be raised. In contrast, if a method is documented as returning a FileStream reference that may or may not be readable, checking the CanRead property before attempting to read data is advisable.
To illustrate the performance impact that using a "run until exception" coding technique can cause, the performance of a cast, which throws an InvalidCastException if the cast fails, is compared to the C# as operator, which returns nulls if a cast fails. The performance of the two techniques is identical for the case where the cast is valid (see Test 8.05), but for the case where the cast is invalid, and using a cast causes an exception, using a cast is 600 times slower than using the as operator (see Test 8.06). The high-performance impact of the exception-throwing technique includes the cost of allocating, throwing, and catching the exception and the cost of subsequent garbage collection of the exception object, which means the instantaneous impact of throwing an exception is not this high. As more exceptions are thrown, frequent garbage collection becomes an issue, so the overall impact of the frequent use of an exception- throwing coding technique will be similar to Test 8.05.
最后无论如何都会执行。如果你的try块成功，它就会执行，如果你的try块失败，它就会执行catch块，然后是finally块。
此外，最好尝试使用以下结构:
using (StreamReader reader=new StreamReader("myfile.txt"))
{
}
由于using语句被自动包装在try / finally语句中，流将自动关闭。(如果想要真正捕获异常，则需要在using语句周围加上try / catch)。
