title: Why doesn't C# have support for first pass exception filtering?
body: <p>Note: this is not <a href="https://stackoverflow.com/questions/181188/c-equivalent-to-vb-net-catch-when">a duplicate of Jeff's question</a>.</p>
  
  <p>That question asked "Is an equivalent?" I know there isn't, and I want to know why!</p>
  
  <p>The reason I ask is that I've only just become clear on how important it is, and the conclusion seems very strange to me.</p>
  
  <p>The Exception Handling block of Microsoft's Enterprise Library advises us to use this pattern:</p>
  
  <pre><code>catch (Exception x)
  {
      if (ExceptionPolicy.HandleException(x, ExceptionPolicies.MyPolicy))
          throw;
  
      // recover from x somehow
  }
  </code></pre>
  
  <p>The policy is defined in an XML file, so that means that if a customer has an issue, we can modify the policy to assist with tracking down (or perhaps papering over) the problem to give them a fast resolution until we deal with it properly - which may involve arguing with 3rd parties, about whose fault it all is. </p>
  
  <p>This is basically an acknowledgement of the simple fact that in real applications the number of exception types and their "recoverability" status is practically impossible to manage without a facility like this.</p>
  
  <p>Meanwhile, the CLR team at MS says this is not an option, and it turns out those guys know what they're talking about! The problem is that right before the <code>catch</code> block runs, any <code>finally</code> blocks nested inside the <code>try</code> block will be executed. So those <code>finally</code> blocks may do any of the following:</p>
  
  <ul>
  <li>Harmlessly modify the program state (phew, lucky).</li>
  <li>Trash something important in the customer's data, because the program state is screwed up to an unknown degree.</li>
  <li>Disguise or destroy important evidence that we need to diagnose an issue - especially if we're talking about calls into native code.</li>
  <li>Throw <em>another</em> exception, adding to the general confusion and misery.</li>
  </ul>
  
  <p>Note that the <code>using</code> statement and C++/CLI destructors are built on <code>try</code>/<code>finally</code>, so they're affected too.</p>
  
  <p>So clearly the <code>catch</code>/<code>throw</code> pattern for filtering exceptions is no good. What is actually needed is a way to filter exceptions, via a policy, without actually catching them and so triggering the execution of <code>finally</code> blocks, unless we find a policy that tells us the exception is safe to recover from.</p>
  
  <p>The CLR team blogged about this recently:</p>
  
  <ul>
  <li><a href="http://blogs.msdn.com/clrteam/archive/2009/02/05/catch-rethrow-and-filters-why-you-should-care.aspx" rel="nofollow noreferrer">Catch, Rethrow and Filters - Why should you care?</a></li>
  <li><a href="http://blogs.msdn.com/clrteam/archive/2009/02/19/why-catch-exception-empty-catch-is-bad.aspx" rel="nofollow noreferrer">Why catch(Exception)/empty catch is bad</a></li>
  </ul>
  
  <p>The outcome is that we have to write a helper function in VB.NET to allow us to access this vital capability from C#. The big clue that there is a problem is that there is code in the BCL that does this. Lots of people have blogged about doing it, but they rarely if ever mention the thing about <code>try</code>/<code>finally</code> blocks, which is the killer.</p>
  
  <p>What I would like to know is:</p>
  
  <ul>
  <li>Are there any public statements or direct emails people have received from the C# team on this subject?</li>
  <li>Are there any existing Microsoft Connect suggestions asking for this? I've heard rumours of them but none of the likely keywords turned up anything.</li>
  </ul>
  
  <p><strong>Update:</strong> as noted above, I have already searched on Microsoft Connect without finding anything. I have also (unsurprisingly) Googled. I've only found people <a href="http://www.codeproject.com/KB/cs/csmverrorhandling.aspx" rel="nofollow noreferrer">explaining why they need this feature</a>, or pointing out the <a href="http://blogs.msdn.com/vbteam/archive/2008/10/09/vb-catch-when-why-so-special.aspx" rel="nofollow noreferrer">advantages of it in VB.NET</a>, or fruitlessly hoping that it will be <a href="http://gregbeech.com/blogs/tech/archive/2006/01/03/why-doesn-t-c-have-exception-filters.aspx" rel="nofollow noreferrer">added in a future version of C#</a>, or <a href="http://blogs.msdn.com/junfeng/archive/2008/12/08/exception-filter.aspx" rel="nofollow noreferrer">working around it</a>, And plenty of <a href="http://msdn.microsoft.com/en-us/magazine/cc300489.aspx" rel="nofollow noreferrer">misleading advice</a>. But no statement on the rationale for omitting it from all current versions of C#. And the reason I'm asking about existing Connect issues is so that (a) I don't create an unnecessary duplicate and (b) I can tell interested people if I have to create one.</p>
  
  <p><strong>Update 2:</strong> Found <a href="http://blogs.msdn.com/ericgu/archive/2004/01/12/57985.aspx" rel="nofollow noreferrer">an interesting old blog post from Eric Gunnerson</a>, formerly of the C# team:</p>
  
  <blockquote>
    <p>"Yes, being able to put a condition on
    a catch is somewhat more convenient
    than having to write the test
    yourself, but it doesn't really enable
    you to do anything new."</p>
  </blockquote>
  
  <p>That was the same assumption I had until it was properly explained to me!</p>