我所遇到下列类型的code很多时候，我不知道这是一个很好的做法（从性能的角度来看）还是不：

I have come across the following type of code many a times, and I wonder if this is a good practice (from Performance perspective) or not:

try
{
    ... // some code
}
catch (Exception ex)
{
    ... // Do something
    throw new CustomException(ex);
}

基本上，在codeR正在做的是，他们一遍涵盖了异常自定义异常和投掷。

Basically, what the coder is doing is that they are encompassing the exception in a custom exception and throwing that again.

如何在性能上不同于以下两种：

How does this differ in Performance from the following two:

try
{
    ... // some code
}
catch (Exception ex)
{
    .. // Do something
    throw ex;
}

或

try
{
    ... // some code
}
catch (Exception ex)
{
    .. // Do something
    throw;
}

撇开任何功能或编码最佳实践的论点，有3个途径之间的性能差异？

Putting aside any functional or coding best practice arguments, is there any performance difference between the 3 approaches?

推荐答案

@Brad Tutterow

@Brad Tutterow

异常没有迷失在第一种情况下，它被传递到构造函数。我会同意你的休息，虽然，第二种方法是因为堆栈跟踪的损失非常糟糕的主意。当我与.NET中，我遇到了很多情况下，其他的程序员就是这样做的，它沮丧我没有尽头，当我需要看到一个异常的真正原因，才发现它从一个巨大的try块，其中被重新抛出我现在不知道问题出在哪里起源。

The exception is not being lost in the first case, it is being passed in to the constructor. I will agree with you on the rest though, the second approach is a very bad idea because of the loss of stack trace. When I worked with .NET, I ran into many cases where other programmers did just that, and it frustrated me to no end when I needed to see the true cause of an exception, only to find it being rethrown from a huge try block where I now have no idea where the problem originated.

我也是第二布拉德的评论，你不应该担心性能。这种微观优化是一个可怕的想法。除非你是在谈论中的每一个迭代循环运行很长一段时间抛出一个异常，你将很可能不是由你的异常使用情况的方式遇到的性能问题。

I also second Brad's comment that you shouldn't worry about the performance. This kind of micro optimization is a HORRIBLE idea. Unless you are talking about throwing an exception in every iteration of a for loop that is running for a long time, you will more than likely not run into performance issues by the way of your exception usage.

总是优化性能，当你有指标，说明你需要优化性能，然后打被证明是罪魁祸首斑点。

Always optimize performance when you have metrics that indicate you NEED to optimize performance, and then hit the spots that are proven to be the culprit.

有好多有可读code，方便调试能力（即不隐藏堆栈跟踪），而不是使一些运行纳秒的速度更快。

It is much better to have readable code with easy debugging capabilities (IE not hiding the stack trace) rather than make something run a nanosecond faster.

有关包装异常的成自定义异常最后需要说明的......这可能是一个非常有用的结构，尤其是与用户界面打交道。你可以用所有已知的和合理的例外情况为一些基本的自定义异常（或一个延伸，从所述基除外），然后用户界面可以正好赶上这个基地的例外。当抓到，除了需要提供显示信息给用户的方式，说ReadableMessage财产，或类似的规定。因此，任何时候，UI忽略了一个例外，那是因为你需要修复的bug，随时随地它捕捉到一个例外，它是可以而且应该得到妥善的处理，用户界面​​的已知错误条件。

A final note about wrapping exceptions into a custom exception... this can be a very useful construct, especially when dealing with UIs. You can wrap every known and reasonable exceptional case into some base custom exception (or one that extends from said base exception), and then the UI can just catch this base exception. When caught, the exception will need to provide means of displaying information to the user, say a ReadableMessage property, or something along those lines. Thus, any time the UI misses an exception, it is because of a bug you need to fix, and anytime it catches an exception, it is a known error condition that can and should be handled properly by the UI.