title: Does exception handling in C# contradict the ECMA-335 standard?
body: <p>My understanding is based on <a href="http://blogs.msdn.com/b/cbrumme/archive/2003/10/01/51524.aspx">this long, but fantastic, article</a> which supports the behavior listed in the C# specification.</p>
  
  <p>The CLI standard (EMCA-335) shows that if there is no suitable catch, the runtime should terminate immediately.  The .NET runtime does not do this, instead it seems to lean toward the behavior of the C# specification (EMCA-334).</p>
  
  <p>First, I find it strange that a language specification is appears to be defining framework behavior.  Secondly, They seem to contradict.</p>
  
  <ul>
  <li>Do they contradict each other, or am I getting the wrong meaning of the document? </li>
  <li>Does a runtime have to go about exception handling in this way to be compliant with the standard?</li>
  </ul>
  
  <p>As an optional question, which one is the "correct" one, as in, if I were to write my own implementation of the CLI which one should I use?  Note that EMCA-335 (CLI) document was updated two months ago, where EMCA-334 (C#) was updated back in 2006.</p>
  
  <hr>
  
  <h3><a href="http://www.ecma-international.org/publications/standards/Ecma-335.htm">ECMA-335 Partition I Section 12.4.2.5</a></h3>
  
  <blockquote>
    <ul>
    <li>When an exception occurs, the CLI searches the array for the first protected block that
    <ul>
    <li>Protects a region including the current instruction pointer and</li>
    <li>Is a catch handler block and</li>
    <li>Whose filter wishes to handle the exception </li>
    </ul></li>
    <li><p>If a match is not found in the current method, the calling method is searched, and so on.  If no match is found the CLI will dump a stack trace and abort the program.</p></li>
    <li><p>If a match is found, the CLI walks the stack back to the point just located, but this time calling the finally and fault handlers. It then starts the corresponding exception handler.</p></li>
    </ul>
  </blockquote>
  
  <h3><a href="http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf">C# Specification §15.9.5 and §15.10</a> (<a href="http://msdn.microsoft.com/en-us/library/ms228593.aspx">§8.9.5 and §8.10 on MSDN</a>)</h3>
  
  <p>The main difference between it and the CLI standard, is that whether or not a catch block is found, the application will not just exist, but will still unwind the stack, and take care of finally handlers.</p>
  
  <p>I would suggest reading the standard itself to get a better meaning of this, since below is a very crude summary.  It outlines step-by-step how a try statement is executed with each possible scenario.</p>
  
  <blockquote>
    <ul>
    <li>In the function that raises the exception:
    <ul>
    <li>Looks for a matching catch clause in each try statement
    <ul>
    <li>Executes the catch statement if it exists</li>
    </ul></li>
    <li>A finally block is executed if it exists</li>
    </ul></li>
    <li>If there was no handler, the above steps are repeated in the calling function</li>
    <li>If the exception processing terminates all function member invocations in the current thread, indicating that the thread has no handler for the exception, then the thread is itself terminated. The impact of such termination is implementation-defined.</li>
    </ul>
  </blockquote>