title: When is it OK to catch an OutOfMemoryException and how to handle it?
body: <p>Yesterday I took part in a discussion on SO devoted to OutOfMemoryException and the pros and cons of handling it (<a href="https://stackoverflow.com/questions/2110436/c-try-catch/2110512#2110512">C# try {} catch {}</a>).</p>
  
  <p>My pros for handling it were:</p>
  
  <ul>
  <li>The fact that OutOfMemoryException was thrown doesn't generally mean that the state of a program was corrupted;</li>
  <li>According to documentation "the following Microsoft intermediate (MSIL) instructions throw OutOfMemoryException: box, newarr, newobj" which just (usually) means that the CLR attempted to find a block of memory of a given size and was unable to do that; it does <em>not</em> mean that no single byte left at our disposition;</li>
  </ul>
  
  <p>But not all people were agree with that and speculated about unknown program state after this exception and an inability to do something useful since it will require even more memory.</p>
  
  <p>Therefore my question is: what are the serious reasons not to handle OutOfMemoryException and immediately give up when it occurs?</p>
  
  <p><strong>Edited:</strong> Do you think that OOME is as fatal as ExecutionEngineException?</p>