抛出异常的性能注意事项

Question

我多次遇到过以下类型的代码,我想知道这是不是一个好的做法(从性能角度来看):

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

基本上,编码器正在做的是它们在自定义异常中包含异常并再次抛出异常.

这与以下两个方面的性能有何不同:

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

要么

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

撇开任何功能或编码最佳实践论点,这3种方法之间是否有任何性能差异？

Answer 1

@Brad Tutterow

在第一种情况下,异常不会丢失,它将被传递给构造函数.我会同意你的意见,第二种方法是一个非常糟糕的主意,因为堆栈跟踪的丢失.当我使用.NET时,我遇到了许多其他程序员就是这样做的情况,当我需要查看异常的真正原因时,它让我感到沮丧,只是发现它是从一个巨大的try块重新抛出的.我现在不知道问题出在哪里.

我也是Brad的评论,你不应该担心性能.这种微观优化是一个可怕的想法.除非您正在讨论在长时间运行的for循环的每次迭代中抛出异常,否则您很可能不会通过异常使用的方式遇到性能问题.

当您拥有指示您需要优化性能的指标时,始终优化性能,然后点击被证明是罪魁祸首的点.

拥有易于调试的可读代码(IE不隐藏堆栈跟踪),而不是让某些东西运行速度快一纳秒,这样做要好得多.

关于将异常包装到自定义异常中的最后一点注释...这可能是一个非常有用的构造,尤其是在处理UI时.您可以将每个已知且合理的异常情况包装到一些基本自定义异常(或从所述基本异常扩展的异常)中,然后UI可以捕获此基本异常.捕获时,异常将需要提供向用户显示信息的方法,比如ReadableMessage属性,或者沿着这些行显示的内容.因此,每当UI错过异常时,都是因为您需要修复的错误,并且只要它捕获异常,它就是一个已知的错误条件,可以并且应该由UI正确处理.