c# - Debug.Assert vs. Specific Thrown Exceptions -


i've started skimming 'debugging ms .net 2.0 applications' john robbins, , have become confused evangelism debug.assert(...).

he points out well-implemented asserts store state, somewhat, of error condition, e.g.:

debug.assert(i > 3, "i > 3", "this means got bad parameter"); 

now, personally, seems crazy me loves restating test without actual sensible 'business logic' comment, perhaps "i <= 3 must never happen because of flobittyjam widgitification process".

so, think asserts kind-of low-level "let's protect assumptions" kind of thing... assuming 1 feels test 1 needs in debug - i.e. protecting against colleague , future programmers, , hoping test things.

but don't is, goes on should use assertions in addition normal error handling; envisage this:

debug.assert(i > 3, "i must greater 3 because of flibbity widgit status"); if (i <= 3) {     throw new argumentoutofrangeexception("i", "i must > 3 because... i=" + i.tostring()); } 

what have gained debug.assert repetition of error condition test? think i'd if talking debug-only double-checking of important calculation...

double interestamount = loan.getinterest(); debug.assert(debuginterestdoublecheck(loan) == interestamount, "mismatch on interest calc"); 

...but don't parameter tests surely worth checking (in both debug , release builds)... or not. missing?

assertions not parameter checking. parameter checking should done (and precisely according pre-conditions specified in documentation and/or specification), , argumentoutofrangeexception thrown necessary.

assertions testing "impossible" situations, i.e., things (in program logic) assume true. assertions there tell if these assumptions broken reason.

hope helps!


Comments

Popular posts from this blog

c++ - How do I get a multi line tooltip in MFC -

asp.net - In javascript how to find the height and width -

c# - DataTable to EnumerableRowCollection -