title: Debug.Assert vs Exceptions
body: <p>Surprisingly I was only able to find one previous question on SO about this subject, and I'd just like to get the community "Vote of Confidence" (or not!) on my approach.</p>
  
  <p>The way I see it is thus:</p>
  
  <ul>
  <li>use <code>Debug.Assert</code> to state things you EXPECT would be true.  This would be used when we are in complete control over our environment, for example in a method to 
  verify some pre and post-conditions.</li>
  <li>use Exceptions when exceptional circumstances arise.  Dealing with external resources, i.e. files, databases, networks etc is a no-brainer.  But...</li>
  </ul>
  
  <p>It gets a little murky in the following scenario.  Please note that this is a CONTRIVED EXAMPLE for illustration only!</p>
  
  <p>Say we have class MyClass, which has a public property MyMode and a method <code>GetSomeValueForCurrentMode()</code>.  Consider MyClass as one intended to be shipped (release built) in a library for use by other developers.</p>
  
  <p>We expect MyMode to be updated by external users of this class.  Now, <code>GetSomeValueForCurrentMode()</code> has the following logic:</p>
  
  <pre><code>switch(MyMode)
  {
  case Mode.ModeA:
  return val1;
  case Mode.ModeB:
  return val2;
  default:
  //Uh-uh this should never happen
  
  }
  </code></pre>
  
  <p>What I'm getting at here is that the user of MyClass has left it in an invalid state.  So what should we do?</p>
  
  <p>In the default, should we <code>Debug.Assert</code> or <code>throw new InvalidOperationException</code> (or other) ?</p>
  
  <p>There is one mantra that says we should not trust users of our classes.  If we choose Debug.Assert and built MyClass as a release build (thereby removing the Debug Asserts) the user of the class wouldn't get helpful information that they had left it in an invalid state.  But it's sort of contrary to the other mantra which says only throw exceptions when things completely out of your control happen.</p>
  
  <p>I find I go round in circles with this - one of those programming debates that don't seem to have a definitive 'correct' answer.  So let's put it to the vote!   </p>
  
  <p>Edit: I noticed this response in a related SO question (<a href="https://stackoverflow.com/questions/117171/design-by-contract-tests-by-assert-or-by-exception">Design by contract using assertions or exceptions?</a>):</p>
  
  <blockquote>
    <p>The rule of thumb is that you should use assertions when you are trying to catch your own errors, and exceptions when trying to catch other people's errors. In other words, you should use exceptions to check the preconditions for the public API functions, and whenever you get any data that are external to your system. You should use asserts for the functions or data that are internal to your system.</p>
  </blockquote>
  
  <p>To me, this makes sense, and can be coupled with the 'Assert then throw' technique outlined below.</p>
  
  <p>Thoughts welcome!</p>