Back to Basic: Debug.Assert(...)
I wonder how many of us litter our code with this particular line? How do you use them? Do you know what you need to watch out when you do use them? Is it necessary to put this line of code in our code? What is the consequence of putting this line into your code? What's the right way to use Debug.Assert? Have you ever stop and think about all these stuffs?
If you are an old timer C/C++ coder, you'd probably have tons of this in your code, at least that's the place I've seen lots of them. Frankly, I don't use them that much. In fact, I'd go as far as saying it's not necessary anymore. Of course I can say this since nowaday, hopefully, a lot of us are already moving toward unit testing, either using TDD (Test Driven Development) or after the fact. So why litter our code with this line when you have a better way to assert the behaviour of our code.
Let's step back a bit, so, what does it do? Well, it will throw an "exception" of sort when the line is executed and the assertion is not satisfied. To be more precice, it will show a dialog box with the "exception" and some buttons that will allow you to Abort, Retry or Ignore the assertion. For example, you have the following code:
const int FIVE = 5;
int a = 2, b = 3;
//All is fine and dandy
Debug.Assert( (a + b) == FIVE);
Console.WriteLine(string.Format("{0} + {1} = {2}", a, b, a + b));
a = 3;
//Uh oh!!
Debug.Assert((a + b) == FIVE);
Console.WriteLine(string.Format("{0} + {1} = {2}", a, b, a + b));When your code hit the second assert, it will go berserk and spit out the following dialog box:
As you can see, that's just not a pretty sight
If you do use them in your code, consider using the overloaded version that will also accept a string message instead the one parameter version.
//Bad
void Debug.Assert(bool condition)
//Better
void Debug.Assert(bool condition, string message)
//Best
void Debug.Assert(bool condition, string message, string detailMessage)
Why? Trust me, you wouldn't want to be bitten with not knowing what's going on when your application stop working if something fails the assertion, especially when the code that have this assert line is a server component.
See the following example:
class Program
{ const int FIVE = 5;
static void Main(string[] args)
{ int a = 2, b = 3;
Foo(a, b);
a = 3;
Bar(a, b);
Console.ReadLine();
}
static void Foo(int a, int b)
{ //Bad Assert, not enough info, might cause headache to maintain
Debug.Assert((a + b) == FIVE);
Console.WriteLine(string.Format("{0} + {1} = {2}", a, b, a + b)); }
static void Bar(int a, int b)
{ //Better Assert, it shows clearly which method is failing
//and description of the assertion that is failing
Debug.Assert((a + b) == FIVE,
"Program.Bar(a,b): Assertion failed!\n" +
"a + b should always equal to 5, but it's not!");
Console.WriteLine(string.Format("{0} + {1} = {2}", a, b, a + b)); }
A call to Foo method will fail misserably when a + b != 5. But when you call Bar, eventhough it will still fail when the assertion is not met, it will fail more gracefully. It will tell you what method is causing the problem and what the problem actually is.
Yes, yes, I experienced this first hand last time when I had to change some rules on my server component and forgot to update the assertion somewhere in the downstream code. Took me a while to figure out why the heck my frontend application just sitting idly and not doing anything and it turned out the server component decided to pop up a dialog box when my new logic hits the the now falsy assertion. And to make thing worse, the dialog box was an empty dialog box with no information whatsoever and a single OK button. So I had to break out the debugger and started doing remote debugging session. After finally stepping through the code I finally figured out that the Debug.Assert line was the culprit. Not fun. If I were to use the overloaded version at least I don't have to start debugging since the info would more than likely be sufficient to tell me that the specific assertion had failed.
Agree, disagree, comment? Let me know...
Happy Asserting.