Basics of Assertion in C#

In this blog we will be explaining the basics of Assertion in C# code.

The use of assert statements can be an effective way to catch program logic errors at runtime, and yet they are easily filtered out of production code. Usually assertions should not be used to check for errors in a user’s input. It may, however, make sense to use assertions to verify that a caller has already checked a user’s input.

In Visual Basic and Visual C#, you can use the Assert method from either Debug or Trace, which are in the System.Diagnostics namespace. Debug class methods are not included in a Release version of your program, so they do not increase the size or reduce the speed of your release code. An assertion interrupts normal operation of the program but does not terminate the application. The Debug.Assert or Trace.Assert method in the System.Diagnostics class provides a way to implement this.

An assertion, or Assert statement, where you specify as an argument to the Assert statement. If the condition evaluates to true, no action occurs. If the condition evaluates to false, the assertion fails. If you are running with a debug build, your program enters break mode.

Usually, you want assertions during development. And In release builds, you usually want assertions to be off to reduce the overhead in release build. But for some release builds it makes sense to have assertions on during the initial stages. Debug.Assert will not be called in the release version of the code. If you want assert to be in the release version then you should replace Debug.Assert with Trace.Assert, which does not disappear in the release version.

Example as we all know that in case of division divisor can never be zero. You might test this using an assertion as shown below

public float Divide(int dividend , int divisor)
{
	Debug.Assert(divisor !=0);
	return  (dividend/ divisor);
}

If we need to check divisor can never be zero in the release build, we can modify the above code as shown below.

public float Divide(int dividend , int divisor)
{
	Trace.Assert(divisor !=0);
	return  (dividend/ divisor);
}

When you use Debug.Assert, make sure that any code inside Assert does not change the results of the program if Assert is removed. Otherwise, you might accidentally introduce a bug that only shows up in the Release version of your program. As shown in following example.

Debug.Assert (DecrementCounter(count) != 0 );

At first glance we can say that above code will work properly and brake whenever condition become false. Here every time whenever “DecrementCounter” Counter is called then value of “count” will be decremented. When you build the Release version, this call to “DecrementCounter” is eliminated, so the “count” does not get updated. Eliminating Call to function will result to bug in the release environment. To avoid such error we can use temporary variable for comparison as shown below.

 int Temp= DecrementCounter(count);
 Debug.Assert(Temp !=0);

As a best coding practice try and avoid using function call inside the assert method.

Parameters of Debug.Assert Method

Assert method will take up to three arguments.

The first argument, which is mandatory, is the condition you want to check. If you call Assert method with only one argument, the Assert method checks the condition and, if the result is false, outputs the contents of the call stack to the Output window.

The second and third arguments are optional parameters. If you call assert method with two or three argument, then method check then condition as per the first parameter and if the result is false, outputs the second and third message strings. Second message is a brief description or title of an error while third message is a detailed description of an error.

Summary

You’ll only need assertions if your code reaches a certain complexity. For example you know that variable A should be not be zero, but the instruction flow up to that point is so complicated that you can’t easily trace it at a glance. That’s when you use an assertion to make sure your program works correctly. There’s not much point to using assertions in simple and obvious code that doesn’t do much internally, like a simple data entry screen. In that case, just use exceptions to test external conditions. The problem with throwing an exception is some calling function might catch it and silently recover. Then you’d never know about your bug. But using an assertion guarantees you’ll be made aware of the bug.

The post Basics of Assertion in C# appeared first on CloudFronts - Dynamics CRM | AX | BI.