title: Handling exceptions, is this a good way?
body: <p>We're struggling with a policy to correctly handle exceptions in our application. Here's our goals for it (summarized):</p>
  
  <ul>
  <li>Handle only specific exceptions.</li>
  <li>Handle only exceptions that you can correct</li>
  <li>Log only once.</li>
  </ul>
  
  <p>We've come out with a solution that involves a generic Application Specific Exception and works like this in a piece of code:</p>
  
  <pre><code>try {
    // Do whatever
  }
  catch(ArgumentNullException ane)
  {
    // Handle, optinally log and continue
  }
  catch(AppSpecificException)
  {
    // Rethrow, don't log, don't do anything else
    throw;
  }
  catch(Exception e)
  {
    // Log, encapsulate (so that it won't be logged again) and throw
    Logger.Log("Really bad thing", e.Message, e);
    throw new AppSpecificException(e)
  }
  </code></pre>
  
  <p>All exception is logged and then turned to an AppSpecificException so that it won't be logged again. Eventually it will reach the last resort event handler that will deal with it if it has to.</p>
  
  <p>I don't have so much experience with exception handling patterns... Is this a good way to solve our goals? Has it any major drawbacks or big red warnings?</p>
  
  <p><strong>Note:</strong> One of the drawbacks of this is that after the first catch you lose the ability to handle an specific exception (if you call a method that calls another method and the second one throws an exception you're not able to handle it) but I've found I've never done this any way ... I only handle exceptions with one level of depth ...</p>