【发布时间】：2011-05-05 15:32:32
【问题描述】：
我们已经看到很多关于何时以及为何使用try/catch 和try/catch/finally 的问题。而且我知道try/finally 肯定有一个用例（特别是因为它是实现using 语句的方式）。
我们还看到了有关 the overhead of try/catch and exceptions 的问题。
但是，我链接到的问题并没有谈到只进行 try-finally 的开销。
假设在try 块中发生的任何事情都没有异常，确保在离开try 块时执行finally 语句（有时通过从函数返回）的开销是多少？
再次，我只询问try/finally，没有catch，没有抛出异常。
谢谢！
编辑：好的，我将尝试更好地展示我的用例。
我应该使用哪个，DoWithTryFinally 或 DoWithoutTryFinally？
public bool DoWithTryFinally()
{
this.IsBusy = true;
try
{
if (DoLongCheckThatWillNotThrowException())
{
this.DebugLogSuccess();
return true;
}
else
{
this.ErrorLogFailure();
return false;
}
}
finally
{
this.IsBusy = false;
}
}
public bool DoWithoutTryFinally()
{
this.IsBusy = true;
if (DoLongCheckThatWillNotThrowException())
{
this.DebugLogSuccess();
this.IsBusy = false;
return true;
}
else
{
this.ErrorLogFailure();
this.IsBusy = false;
return false;
}
}
这种情况过于简单，因为只有两个返回点，但想象一下，如果有四个……或十个……或一百个。
出于以下原因，我有时会想使用try/finally：
- 遵守 DRY 原则（尤其是在退出点数量越来越多的情况下）
- 如果事实证明我的内部函数没有抛出异常是错误的，那么我想确保将
this.Working设置为false。
假设考虑到性能问题、可维护性和 DRY 原则， 退出点的数量（特别是如果我可以假设所有内部异常都被捕获）我想承担与try/finally相关的任何性能损失？
编辑 #2： 我将 this.Working 的名称更改为 this.IsBusy。抱歉，忘了说这是多线程的（尽管实际上只有一个线程会调用该方法）；其他线程将轮询以查看对象是否正在工作。如果工作按预期进行，返回值只是成功或失败。
【问题讨论】：
-
我不完全理解这个问题。您仍在编组，只是没有发现异常。仍然必须进行编组，对吗？
-
我想我们其他人都理解这个问题。这是一个很好的。
-
@DOK (+1) ~ 我也觉得这很好，我想我想明白了：我想这和“如果我没有发生任何坏事，保险的费用是多少”是一样的？” ...我认为如果没有抛出异常，就会产生成本，但无论如何你还是要付出代价。
-
如果你有一百个返回点我认为你应该重构:-)
-
@drachenstern：是的，你基本上已经明白了。请查看我的更新版本，以更好地了解我的目标。
标签： c# .net performance try-finally