虽然许多其他答案提供了很好的示例，说明为什么您可能希望捕获重抛出异常，但似乎没有人提到“最终”场景。

举个例子，你有一个方法，你在其中设置了游标(例如一个等待游标)，该方法有几个出口点(例如if () return;)，你想确保游标在方法结束时被重置。

为此，您可以将所有代码包装在try/catch/finally中。在最后将光标设置回右光标。这样就不会隐藏任何有效的异常，在catch中重新抛出它。

try
{
    Cursor.Current = Cursors.WaitCursor;
    // Test something
    if (testResult) return;
    // Do something else
}
catch
{
    throw;
}
finally
{
     Cursor.Current = Cursors.Default;
}

在你发布的代码中的例子中，事实上，捕捉异常没有任何意义，因为在捕捉上没有做任何事情，它只是重新抛出，事实上它弊大于利，因为调用堆栈丢失了。

但是，您可以捕获异常来执行一些逻辑(例如关闭文件锁的sql连接，或者只是一些日志记录)，在发生异常时将其扔回调用代码来处理。这在业务层中比在前端代码中更常见，因为您可能希望实现业务层的编码器处理异常。

在你发布的例子中，捕捉异常是没有意义的。不要那样做!

c#(在c# 6之前)不支持CIL“过滤异常”，而VB支持，因此在c# 1-5中，重新抛出异常的一个原因是在catch()时没有足够的信息来确定是否要真正捕获异常。

例如，在VB中你可以做到

Try
 ..
Catch Ex As MyException When Ex.ErrorCode = 123
 .. 
End Try

.．.它不会处理具有不同ErrorCode值的myexception。在v6之前的c#中，如果ErrorCode不是123，你必须捕获并重新抛出MyException:

try 
{
   ...
}
catch(MyException ex)
{
    if (ex.ErrorCode != 123) throw;
    ...
}

从c# 6.0开始，你可以像VB一样过滤:

try 
{
  // Do stuff
} 
catch (Exception e) when (e.ErrorCode == 123456) // filter
{
  // Handle, other exceptions will be left alone and bubble up
}

当您没有特定的代码来处理当前异常时，或者当您有处理特定错误情况的逻辑但想要跳过所有其他情况时，通过throw重新抛出异常非常有用。

例子:

string numberText = "";
try
{
    Console.Write("Enter an integer: ");
    numberText = Console.ReadLine();
    var result = int.Parse(numberText);

    Console.WriteLine("You entered {0}", result);
}
catch (FormatException)
{
    if (numberText.ToLowerInvariant() == "nothing")
    {
        Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
    }
    else
    {
        throw;
    }
}    
finally
{
    Console.WriteLine("Freed some resources.");
}
Console.ReadKey();

然而，还有另一种方法，在catch块中使用条件子句:

string numberText = "";
try
{
    Console.Write("Enter an integer: ");
    numberText = Console.ReadLine();
    var result = int.Parse(numberText);

    Console.WriteLine("You entered {0}", result);
}
catch (FormatException) when (numberText.ToLowerInvariant() == "nothing")
{
    Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
}    
finally
{
    Console.WriteLine("Freed some resources.");
}
Console.ReadKey();

这种机制比重新抛出异常更有效，因为 的。net运行时不需要重新构建异常对象 然后再扔出去。

这取决于您在catch块中所做的事情，以及您是否希望将错误传递给调用代码。

你可能会说Catch io。FileNotFoundExeption ex，然后使用替代文件路径或类似的，但仍然抛出错误。

同样，使用Throw而不是Throw Ex可以让你保持完整的堆栈跟踪。Throw ex从Throw语句重新启动堆栈跟踪(我希望这有意义)。

抱歉，但许多“改进设计”的例子仍然很糟糕，或者可能会极具误导性。有try {} catch {log;Throw}完全没有意义。异常日志应该在应用程序的中心位置完成。无论如何，异常都会出现在堆栈跟踪中，为什么不将它们记录在系统边界附近的某个地方呢?

Caution should be used when you serialize your context (i.e. DTO in one given example) just into the log message. It can easily contain sensitive information one might not want to reach the hands of all the people who can access the log files. And if you don't add any new information to the exception, I really don't see the point of exception wrapping. Good old Java has some point for that, it requires caller to know what kind of exceptions one should expect then calling the code. Since you don't have this in .NET, wrapping doesn't do any good on at least 80% of the cases I've seen.