title: Overhead of try/finally in C#?
body: <p>We've seen plenty of questions about when and why to use <code>try</code>/<code>catch</code> and <code>try</code>/<code>catch</code>/<code>finally</code>. And I know there's definitely a use case for <code>try</code>/<code>finally</code> (especially since it is the way the <code>using</code> statement is implemented).</p>
  
  <p>We've also seen questions about <a href="https://stackoverflow.com/questions/52312/what-is-the-real-overhead-of-try-catch-in-c">the overhead of try/catch and exceptions</a>.</p>
  
  <p>The question I linked to, however, doesn't talk about the overhead of having JUST try-finally.</p>
  
  <p>Assuming there are no exceptions from anything that happens in the <code>try</code> block, what's the overhead of making sure that the <code>finally</code> statements get executed on leaving the <code>try</code> block (sometimes by returning from the function)?</p>
  
  <p>Again, I'm asking ONLY about <code>try</code>/<code>finally</code>, no <code>catch</code>, no throwing of exceptions.</p>
  
  <p>Thanks!</p>
  
  <p><b>EDIT:</b> Okay, I'm going to try to show my use case a little better.</p>
  
  <p>Which should I use, <code>DoWithTryFinally</code> or <code>DoWithoutTryFinally</code>?</p>
  
  <pre><code>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;
    }
  }
  </code></pre>
  
  <p>This case is overly simplistic because there are only two return points, but imagine if there were four... or ten... or a hundred.</p>
  
  <p>At some point I would want to use <code>try</code>/<code>finally</code> for the following reasons:</p>
  
  <ul>
  <li>Keep to DRY principles (especially as the number of exit points gets higher)</li>
  <li>If it turns out that I'm wrong about my inner function not throwing an exception, then I want to make sure <code>this.Working</code> is set to <code>false</code>.</li>
  </ul>
  
  <p>So hypothetically, given <i>performance concerns, maintainability, and DRY principles,</i> for what number of exit points (especially if I <i>can</i> assume that all inner exceptions are caught) do I want to incur whatever performance penalty is associated with <code>try</code>/<code>finally</code>?</p>
  
  <p><b>EDIT #2:</b> I changed the name of <code>this.Working</code> to <code>this.IsBusy</code>. Sorry, forgot to mention this is multithreaded (though only one thread will ever actually call the method); other threads will be polling to see if the object is doing its work. The return value is merely success or failure for if the work went as expected.</p>