所以我正在处理这个代码库，每个方法都包含在一个try-catch块中，该块只将异常记录到一个日志文件中。

我正在考虑挥手改变这一点，但我一个月后就走了，我不确定这会减慢代码的速度。是的，这是可怕的练习，但这是本课程的标准。是的，它使错误更难调试，但它"更容易"。

这里的人的决定因素是速度。所以我想知道这会使代码慢多少？我在向比我更了解编译器的人征求大概的估计。

我知道有很多重复的问题，关于异常是否会减慢速度，它取决于编译器版本等，但我在这里寻找更多的建议。我也很好奇。

它可能不会减慢正在运行的应用程序的速度，因为在抛出异常之前，它实际上不会做任何事情。(除非你真的想要压缩每一点性能，而且大多数应用程序不需要这样做。更不用说，这种编码方式意味着这个应用程序可能还有许多其他更普遍的问题。)

它所做的就是用大量不必要的异常捕获来污染代码。(注意抓取和有意义的处理之间的区别。我可以向您保证，这段代码是在做前一段代码，而不是后一段代码。)这会减慢开发速度，开发时间比系统时间的毫秒要昂贵得多。

Yeah, it's horrible practice, but that's par for the course.

听起来你已经走了：)

Yeah, it makes errors more difficult to debug, but it's"easier".

这是两个相互排斥的陈述。这不可能既困难又容易。有人认为这会更容易。他们错了。

How much would wrapping every method in try-catch blocks slow a program down?

以开发时间来衡量，很多。

在每个方法中加入一个try/catch来捕获一般的异常，结果会因为性能以外的原因而变得很痛苦。即，无论应用程序的状态如何，应用程序都将继续"运行"。换句话说，并非所有的异常都可以或应该被处理。例如，当数据库关闭、电子邮件服务器、坏事务(或者应该是事务性的但不是因为糟糕的设计)等时会发生什么？

我在类似的环境中工作过。最终关注的不是性能。我害怕把"业绩原因"作为一个笼统的含糊不清的地方，抓住所有的理由做出其他的强制性决定……我离题了。

但是，如果你在一个月内外出，我提醒你考虑这个论点是否有必要。开发车间已经证明低于您的标准。重要的是不要烧了一座桥，因为一个坏的参考可能会让你失去一个未来的职位。

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

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