Note that there are some explanatory texts on larger screens.

plurals
  1. POWhy doesn't C# have support for first pass exception filtering?
    text
    copied!<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>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload