title: Debug.Assert vs. Specific Thrown Exceptions
body: <p>I've just started skimming 'Debugging MS .Net 2.0 Applications' by John Robbins, and have become confused by his evangelism for Debug.Assert(...).</p>
  
  <p>He points out that well-implemented Asserts store the state, somewhat, of an error condition, e.g.:</p>
  
  <pre><code>Debug.Assert(i &gt; 3, "i &gt; 3", "This means I got a bad parameter");
  </code></pre>
  
  <p>Now, personally, it seems crazy to me that he so loves restating his test without an actual sensible 'business logic' comment, perhaps "i &lt;= 3 must never happen because of the flobittyjam widgitification process".</p>
  
  <p>So, I think I get Asserts as a kind-of low-level "Let's protect my assumptions" kind of thing... assuming that one feels this is a test one only needs to do in debug - i.e. you are protecting yourself against colleague and future programmers, and hoping that they actually test things.</p>
  
  <p>But what I don't get is, he then goes on to say that you should use assertions in addition to normal error handling; now what I envisage is something like this:</p>
  
  <pre><code>Debug.Assert(i &gt; 3, "i must be greater than 3 because of the flibbity widgit status");
  if (i &lt;= 3)
  {
      throw new ArgumentOutOfRangeException("i", "i must be &gt; 3 because... i=" + i.ToString());
  }
  </code></pre>
  
  <p>What have I gained by the Debug.Assert repetition of the error condition test? I think I'd get it if we were talking about debug-only double-checking of a very important calculation...</p>
  
  <pre><code>double interestAmount = loan.GetInterest();
  Debug.Assert(debugInterestDoubleCheck(loan) == interestAmount, "Mismatch on interest calc");
  </code></pre>
  
  <p>...but I don't get it for parameter tests which are surely worth checking (in both DEBUG and Release builds)... or not. What am I missing?</p>