当没有抛出异常时，try / catch块是否会损害性能？

Question

当没有抛出异常时，try / catch块是否会损害性能？

在与Microsoft员工进行代码审查期间，我们在try{}块中遇到了大量代码。她和IT代表建议这可能会影响代码的性能。事实上，他们建议大多数代码应该在try / catch块之外，并且只应该检查重要的部分。微软员工补充说，即将发布的白皮书警告不要使用不正确的try / catch块。

我环顾四周，发现它可以影响优化，但它似乎只适用于范围之间共享变量。

我不是在询问代码的可维护性，甚至不是在处理正确的异常（有问题的代码需要重新分解，毫无疑问）。我也没有提到使用流量控制的异常，这在大多数情况下显然是错误的。这些都是重要的问题（有些更重要），但不是重点。

如果不抛出异常，try / catch块如何影响性能？

Answer 1

对.NET异常模型的全面解释。Rico Mariani的表演花絮：例外成本：什么时候投掷，何时投注第一种成本是在代码中进行异常处理的静态成本。托管异常实际上在这里做得比较好，我的意思是静态成本可以比C ++中的低得多。为什么是这样？好吧，静态成本实际上是在两种情况下产生的：首先，try / finally / catch / throw的实际站点，其中有这些构造的代码。其次，在无人值守的代码中，存在与跟踪在抛出异常时必须被破坏的所有对象相关联的隐形成本。必须存在相当数量的清理逻辑，而且偷偷摸摸的部分就是那些甚至没有代码的代码。Dmitriy Zaslavskiy：根据Chris Brumme的说明：还有一个成本与JIT在捕获存在时没有执行某些优化有关