C# Using Debug.Assert

Debug.Assert is a member of the System.Diagnostics library that can be used to validate a condition, pausing the running of an application is the condition is not satisfied.

Quoting from Code Complete (I highly suggest giving it a read if you haven’t already);

8 Defensive Programming

8.2 Assertions

An assertion is code that’s used during development—usually a routine or macro—that allows a program to check itself as it runs. When an assertion is true, that means everything is operating as expected. When it’s false, that means it has detected an unexpected error in the code. For example, if the system assumes that a customer-information file will never have more than 50,000 records, the program might contain an assertion that the number of records is lessthan or equal to 50,000. As long as the number of records is less than or equal to 50,000, the assertion will be silent. If it encounters more than 50,000 records, however, it will loudly “assert” that there is an error in the program.

Assertions are especially useful in large, complicated programs and in high reliability programs. They enable programmers to more quickly flush out mismatched interface assumptions, errors that creep in when code is modified, and so on.

An assertion usually takes two arguments: a boolean expression that describes the assumption that’s supposed to be true and a message to display if it isn’t.

Asserts should be used to sanity check against developer assumptions.

Debug.Assert is, as you can probably (hopefully) guess at this point, an assertion. One that runs in debug mode only. Once the application is compiled into release mode, the debug.assert is dropped from the compilation. They can be used as sanity checks in certain points of an application, and the c# implementation, Debug.Assert, will pause the running of an application and provided the current call stack and a bespoke message, provided by the developer.

Using Debug.Assert allows us to catch unexpected conditions and, as stated above, to check assumptions we have made as developers.

For example, consider the following method;


public string ReturnVal(string val)

{
    if (val == null) throw new ArgumentNullException("val");
    return val;
}

Harmless in itself, but consider the following;


string myValue = "Default Value";

try

{

    myValue = ReturnVal(myClass.Value);

}

catch(Exception) //Eugh, only here to prove a point

{

    //Do nothing

}

// .... Some other code to save myValue in the database

Without a constant breakpoint, we could end up saving “Default Value” in a database record, assuming that the value has never changed, when in fact myClass wasn’t loaded properly in the first place, and should have been handled better. (I know, poor case example.)

In order to force the application to pause if val is null, we can use Debug.Assert, and if the situation arises, we’ll be aware of it.


public string ReturnVal(string val)

{
if (val == null)
{
    Debug.Assert(false, "Val is null: " + val);
    throw new ArgumentNullException("val");
}

return val;
}

Using the above alteration, if val is ever null, the application will pause, in debug mode only, and return the error message. The boolean value represents the condition Debug.Assert is checking, and could also have been written as;


Debug.Assert(val != null), "Val is null: " + val); 

 

Debug.Assert can’t leak through into production code (Release Builds). However, should these be a need to continue using asserts in production, Trace.Assert can be used in it’s place.

This does come with an overhead.

About Adam Riddick

When not Developing, Adam moonlights as a climbing frame for his two children. Adam Riddick was founded in 1987, in County Durham, England. Read More ...

21. November 2014 by Adam Riddick
Categories: C#, Tips | Leave a comment

Inspire me with your wisdom ...