Debug.Assert puzzle!

[emma middlebrook]

I have a question regarding asserting ... here's some code:

string GetAssertMessag e()
{
... prepare a message string and return it...
}

void SomeMethod()
{
...
Debug.Assert(co ndition, GetAssertMessag e());
...
}

Even if condition is true, GetAssertMessag e() will still be evaluated
as it's a parameter to a function. How can I best avoid the cost of
GetAssertMessag e() if the condition is false and not in DEBUG mode? I
also read that I shouldn't really put function calls into an Assert
statement (MSDN "Assertions in Managed Code").

Idea 1:

#ifdef DEBUG

string GetAssertMessag e()
{
... prepare a message string ...
}

#endif

void SomeMethod()
{
...
#ifdef DEBUG
if (!condition)
{
string message = GetAssertMessag e();

// could use Debug.Fail without condition
Debug.Assert(co ndition, GetAssertMessag e());
}
#endif
}

Surely there must be something a little more elegant than this? It
just makes the code ugly.

Any ideas or have I done the best I can here?

Thanks!

Emma Middlebrook
em************* @fastmail.fm

[Jon Skeet [C# MVP]]

emma middlebrook <em************ **@fastmail.fm> wrote:

I have a question regarding asserting ... here's some code:

string GetAssertMessag e()
{
... prepare a message string and return it...
}

void SomeMethod()
{
...
Debug.Assert(co ndition, GetAssertMessag e());
...
}

Even if condition is true, GetAssertMessag e() will still be evaluated
as it's a parameter to a function. How can I best avoid the cost of
GetAssertMessag e() if the condition is false and not in DEBUG mode? I
also read that I shouldn't really put function calls into an Assert
statement (MSDN "Assertions in Managed Code").

If you don't have DEBUG defined, it won't get evaluated at all. Here's
some sample code:

using System;
using System.Diagnost ics;

public class Test
{
static void Main(string[] args)
{
Debug.Assert (true, GetMessage());
}

static string GetMessage()
{
Console.WriteLi ne ("GetMessage called");
return "message";
}
}

When DEBUG is defined, "GetMessage called" will be produced on the
console. When it's not, the message won't appear.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[emma middlebrook]

Jon

Thanks for your reply ...

If you don't have DEBUG defined, it won't get evaluated at all.

Yes, I got that far :-) I was really more interested in whether anyone
had a better way than the below usage of the DEBUG symbol i.e. using
the preprocessor *as well as* testing for the condition *as well as*
using Debug.Fail or Debug.Assert in that block too! Something just
doesn't seem right about this code - looks a bit clumsy. Or am I
worrying too much?

#ifdef DEBUG
string GetAssertMessag e()
{
... prepare a message string ...
}
#endif

void SomeMethod()
{
...
#ifdef DEBUG
if (!condition)
{
string message = GetAssertMessag e();

// could use Debug.Fail without condition
Debug.Assert(co ndition, GetAssertMessag e());
}
#endif
}

Thanks!

Emma Middlebrook
em************* *@fastmail.fm

[Jon Skeet [C# MVP]]

emma middlebrook <em************ **@fastmail.fm> wrote:

Thanks for your reply ...

If you don't have DEBUG defined, it won't get evaluated at all.

Yes, I got that far :-) I was really more interested in whether anyone
had a better way than the below usage of the DEBUG symbol i.e. using
the preprocessor *as well as* testing for the condition *as well as*
using Debug.Fail or Debug.Assert in that block too! Something just
doesn't seem right about this code - looks a bit clumsy. Or am I
worrying too much?

I think you're worrying too much - what's wrong with just:

Debug.Assert (condition, GetAssertMessag e());

?

GetAssertMessag e doesn't get invoked when DEBUG isn't defined, so
what's the disadvantage? You end up with a *slightly* larger assembly
(as the method is still present) but it'll never even be JITted.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[mikeb]

emma middlebrook wrote:

Jon

Thanks for your reply ...

If you don't have DEBUG defined, it won't get evaluated at all.

Yes, I got that far :-) I was really more interested in whether anyone
had a better way than the below usage of the DEBUG symbol i.e. using
the preprocessor *as well as* testing for the condition *as well as*
using Debug.Fail or Debug.Assert in that block too! Something just
doesn't seem right about this code - looks a bit clumsy. Or am I
worrying too much?

#ifdef DEBUG
string GetAssertMessag e()
{
... prepare a message string ...
}
#endif

void SomeMethod()
{
...
#ifdef DEBUG
if (!condition)
{
string message = GetAssertMessag e();

// could use Debug.Fail without condition
Debug.Assert(co ndition, GetAssertMessag e());
}
#endif
}

You could write your own Assert() wrapper method, decorate it with the
ConditionalAttr ibute so it only gets called when DEBUG is defined:

public class MyDebug {
[System.Diagnost ics.Conditional Attribute( "DEBUG")]
public static void Assert( bool condition) {
if (!condition) {
string msg = GetAssertMessag e();
System.Diagnost ics.Debug.Asser t(condition, msg);
}
}
}
Now, replace your Debug.Assert() calls with calls to MyDebug.Assert( ).
GetAssertMessag e() will only be evaluated when the assertion condition
fails, and the ConditionalAttr ibute tells the compiler to not bother
putting the IL for calls to the MyDebug.Assert( ) method in the assembly
unless DEBUG is defined.

Depending on the deployment requirements of your application, and
whether or not calls to MyDebug.Assert are made from different
assemblies than where MyDebug is implemented, you may want to place the
*body* (not the entire definition) of MyAssert() inside an "#if DEBUG"
block, because the ConditionalAttr ibute only affects the calls to the
method - the method itself still gets compiled to IL, regardless of the
build type.

You might want to decorate GetAssertMessag e() with the conditional
attribute as well, instead of placing it inside an "#if DEBUG" block.

Now that I mentioned that, I'll bet one reason you asked this question
is because you get compiler errors when calls to GetAssertMessag e() are
not inside an "#if DEBUG" block. Simply using the ConditionalAttr ibute
on it will fix that problem.

If your problem is really that actual runtime calls to
GetAssertMessag e() are too expensive in a DEBUG build, then you will
probably need to go with my first suggestion.

--
mikeb