在try-catch块中包装每个方法会减少多少程序？

Question

所以我正在研究这个代码库，并且每个方法都包含在try-catch块中，它只是将异常记录到日志记录文件中。

我正在考虑挥手并尝试改变这种情况，但我已经离开了一个月，而且我不确定这会让代码减少多少。是的，这是一种可怕的做法，但这对于球场而言是相同的。是的，它使错误调试更加困难，但它“更容易”。

这里人们的决定因素是速度。所以我想知道这会让代码变得多慢多少？我要求对比我更了解编译器的人进行评估。

我知道有很多关于异常是否会减慢事情的重复问题，并且它根据编译器版本等而有所不同，但我在这里寻找更多的因素/一些建议。我也很好奇。

Answer 1

这可能不会减慢正在运行的应用程序的速度，因为在抛出异常之前它实际上并没有做任何事情。 （除非你真的试图挤压每个位性能，并且大多数应用程序都不需要这样做。更不用说这种编码风格非常强烈地暗示这个应用程序可能< / em>还有很多其他更普遍的问题。）

它正在做的是用大量不必要的异常捕获来污染代码。 （注意捕获和有意义地处理之间的区别。我可以保证这个代码正在执行前者，不是后者。）它正在减速开发开发，开发人员的工作时间比毫秒的系统时间贵很多。

  

是的，这是一种可怕的做法，但这与课程相提并论。

听起来你已经离开了：）

  

是的，它使错误调试更加困难，但它“更容易”。

这是两个相互排斥的陈述。 和更难以实现。某人想到会更容易。他们错了。

  

在try-catch块中包装每个方法会减少多少会减慢程序的速度？

在开发时间内测量，很多。

Answer 2

在每个方法中使用try / catch来捕获一般异常最终会因为性能以外的原因而感到痛苦。即，无论应用程序的状态如何，应用程序都继续“运行”。换句话说，并非所有例外都可以或应该被处理。例如。当数据库出现故障，电子邮件服务器，一个糟糕的事务（或者应该是事务性的但不是因为设计不佳）等等会发生什么......？

我在类似的环境中工作过。最终的担忧不是表现。我担心那些把“表现原因”作为一般性模糊，全部理由做出其他决定性做法的地方......我离题了。

但是，如果你在一个月内外出，那么我提醒你考虑一下这个论点是否合理。开发车间已证明低于您的标准。重要的是不要烧掉一座桥，因为糟糕的参考可能会让你失去一个未来的位置。

Answer 3

try块中的代码受限于编译器如何优化它。实际上，如果使用try / catch包装每个方法，则会限制优化。请参阅http://msmvps.com/blogs/peterritchie/archive/2007/06/22/performance-implications-of-try-catch-finally.aspx和http://msmvps.com/blogs/peterritchie/archive/2007/07/12/performance-implications-of-try-catch-finally-part-two.aspx

性能受影响的程度将取决于应用程序。