Java folks, please don’t get scared off by the C# examples, the contents of the post apply regardless if it is java or C#.
None of us use Asserts enough. It’s that simple, we don’t. Asserts are essentially a way to ensure we don’t get a value we shouldn’t have. The great thing about using asserts is that they aren’t included in final code (compiled in “Release”), only code complied with “Debug”. They make testing easier by verifying that when code is being tested in Debug that it doesn’t go beyond some condition. They can also be used to ensure when troubleshooting that you have the values you should.
Take a look at the code below:
private void pass_Click(object sender, RoutedEventArgs e)
{
int temp = 1;
Debug.Assert(temp > 0);
MessageBox.Show(“Pass”);
}
private void fail_Click(object sender, RoutedEventArgs e)
{
int temp = -1;
Debug.Assert(temp > 0);
MessageBox.Show(“Fail”);
}
This is a sample of using an assert. I know the example is trivial but I wanted to show a simple use of it. These are simply a Click event on a “Pass” button and a Click event on a “Fail” button. I would recommend you create your own solution and put these on a pass and fail button so you can see and understand what happens when Debug.Assert is called.
Now lately I’ve been coming across a lot of code like (anonymous-ized for your protection):
{
MessageBox.Show(“ERROR: YOU SHOULD NEVER SEE THIS MESSAGE. Invalid TransformString!”, “SERIOUS ERROR occurred in MyClass:MyMethod”, MessageBoxButton.OK, MessageBoxImage.Error);
}
I’m sorry but this is simply wrong.
Code Complete 2nd edition has a great chapter on Assertions. The above example is exactly where asserts should be used.
Per the guidelines for “Using Assertions” (McConnnel, Code Complete 2, 2004) the following guidelines should apply for using assertions:
“Use error-handling code for conditions you expect to occur; use assertions for conditions that should never occur.
Avoid putting executable code into assertions.
Use assertions to document and verify preconditions and post conditions.
For highly robust code, assert and then handle the error anyway.”
That’s right. The very first usage guideline says to use asserts for conditions that should never occur.
Take a look at a sample from Code Complete (originally VB but I ported it to C#):
{
//Verify preconditions
Debug.Assert(Latitude >= -90 && Latitude <= 90, “Invalid Latitude”);
Debug.Assert(Longitude >= 0 && Longitude <= 360, “Invalid Longitude”);
Debug.Assert(Elevation >= -500 && Elevation <= 75000, “Invalid Elevation”);
/* DO THE WORK */ //Verify postconditions
Debug.Assert(velocity >= 0 && velocity <= 600,
“Invalid Velocity”,
“Can’t seem to properly work the velocity formula”);
return velocity;
}
On this McConnell has to say:
“If the variables Latitude, Longitude, and Elevation were coming from an external source, invalid values should be checked and handled by error-handling code rather then by assertions. If the variables are coming from a trusted, internal source, however, and the routine’s design is based on the assumption that these values will be withn their valid ranges, then assertions are appropriate.” (McConnell, 2004)
Now assertions aren’t the end-all, be-all of validating values. Chances are that in most cases you are still going to want to validate and do error checking. But they’re a good start.
And just for the java folks that hung around, an assert in java:
assert denominator != 0: “denominator is 0”;
Refs:
Code Complete (Second Edition), Microsoft Press, Steve McConnell, 2004
And just for the java folks:
Programming With Assertions
