title: .NET and C# Exceptions. What is it reasonable to catch
body: <p>Disclaimer, I'm from a Java background. I don't do much C#. There's a great deal of transfer between the two worlds, but of course there are differences and one is in the way Exceptions tend to be thought about.</p>
  
  <p>I recently answered a C# question suggesting that under some circstances it's reasonable to do this:</p>
  
  <pre><code> try {
     some work
   } catch (Exeption e) {
         commonExceptionHandler();
   }
  </code></pre>
  
  <p>(The reasons why are immaterial). I got a response that I don't quite understand:</p>
  
  <blockquote>
    <p>until .NET 4.0, it's very bad to catch
    Exception. It means you catch various
    low-level fatal errors and so disguise
    bugs. It also means that in the event
    of some kind of corruption that
    triggers such an exception, any open
    finally blocks on the stack will be
    executed, so even if the
    callExceptionReporter fuunction tries
    to log and quit, it may not even get
    to that point (the finally blocks may
    throw again, or cause more corruption,
    or delete something important from the
    disk or database).</p>
  </blockquote>
  
  <p>May I'm more confused than I realise, but I don't agree with some of that. Please would other folks comment. </p>
  
  <ol>
  <li><p>I understand that there are many low level Exceptions we don't want to swallow. My commonExceptionHandler() function could reasonably rethrow those. This seems consistent with <a href="https://stackoverflow.com/questions/55859/catching-all-types-of-exceptions-in-c-in-one-catch-block/55863#55863">this answer</a> to a related question. Which does say "Depending on your context it can be acceptable to use catch(...), providing the exception is re-thrown." So I conclude using catch (Exception ) is not always evil, silently swallowing certain exceptions is.</p></li>
  <li><p>The phrase "Until .NET 4 it is very bad to Catch Exception" What changes in .NET 4? IS this a reference to AggregateException, which may give us some new things to do with exceptions we catch, but I don't think changes the fundamental "don't swallow" rule.</p></li>
  <li><p>The next phrase really bothers be. Can this be right?</p></li>
  </ol>
  
  <blockquote>
    <p>It also means that in the event
    of some kind of corruption that
    triggers such an exception, any open
    finally blocks on the stack will be
    executed (the finally blocks may
    throw again, or cause more corruption,
    or delete something important from the
    disk or database)</p>
  </blockquote>
  
  <p>My understanding is that if some low level code had</p>
  
  <pre><code>lowLevelMethod() {
      try {
          lowestLevelMethod();
      } finally {
           some really important stuff
      }
  }
  </code></pre>
  
  <p>and in my code I call lowLevel();</p>
  
  <pre><code> try {
        lowLevel()
   } catch (Exception e) {
         exception handling and maybe rethrowing
   }
  </code></pre>
  
  <p>Whether or not I catch Exception this has no effect whatever on the excution of the finally block. By the time we leave lowLevelMethod() the finally has already run. If the finally is going to do any of the bad things, such as corrupt my disk, then it will do so. My catching the Exception made no difference. If It reaches my Exception block I need to do the right thing, but I can't be the cause of dmis-executing finallys</p>