(originally published in The Borland Developer Network)
As part of good programming, assertions in your code are a convenient way to monitor what is happening. This article discusses adding flexibility to assert(), as well as improving your use of it.
Some Background on Asserting
For many years, I’ve used assert() to manage code:
assert(int test)
This function takes a test and asserts the test result is true – nothing happens if so, but false results in an alert, allowing your program to detect errors conveniently. The beauty of assert() is that it is also a macro, meaning that if you #define NDEBUG, the assert macro disappears from your code, leaving nothing behind.
While this makes it useful for checking for problems in code, there are some problems with assert() itself:
- The default for a failed assertion is to abort the program, making an assertion a rather final test.
- assert() tests each time it is reached, making it awkward to use in a loop.
- It’s awkward to examine code; since assert() normally calls abort(), it’s not possible to fail an assertion and continue debugging.
The ASSERTING() Macro
Of course, these problems are exactly those solved in this article. By modifying assert(), we get a more robust and useful way to verify code. The result is a macro package I call ASSERTING(), both to make it stand out in code, and to differentiate it from assert(). It is included in the files assert2.cpp/.dfm/.h:
ASSERTING(int test,char *errorMessage);
As with the regular assert(), NDEBUG determines whether the code is actually created or not.
The macro in the header file shows how it should be processed. If NDEBUG is not defined, the following code is expanded at each ASSERTING() call:
#define ASSERTING(test,msg)
{
if (!(test))
{
static int callIt=1;
if (callIt)
{
if (HandleAsserting(#test,#msg,__FILE__,__LINE__,&callIt))
{ _asm { int 3 } }
}
}
}
The macro uses a static variable to determine if the call is made. Our subroutine HandleAsserting() can turn off this static, allowing us to disable future testing at this location (for instance, after the first failure in a loop). Returning true from the function executes the assembly call ‘int 3’, which breaks to the debugger just after the assertion.
Trio of Options
Combining these features, the HandleAsserting() call has three options:
- Prevent further testing and ‘firing’ of the assertion by setting callIt to zero.
- Break to the debugger by returning true.
- Continue execution by returning false.
A simple non-VCL implementation does this, and is included the assert2.cpp file at the end (but commented out):
int HandleAsserting(char *testStr,char *msgStr,char *fileStr,int line,int *callFlag)
{
// assert message & and return flag regarding aborting - callFlag set if repeating forbidden
static char s_text[199]=""; // don't assign dynamically in case 'out of memory' error
wsprintf(s_text,"FAILED: %srn"
"Error: ( %s )rn"
"File '%s', Line %drn"
"Abort execution, allow assert Retry, or Ignore in future?",
msgStr,testStr,fileStr,line);
switch ( ::MessageBox(NULL,s_text,"ASSERTION ERROR",MB_ABORTRETRYIGNORE) )
{
case IDIGNORE: // prevent calling again - turn off flag
*callFlag=0; // never call again
break;
case IDABORT: // return flag and break
return 1; // abort/break
}
return 0;
}
This function calls MessageBox() to display the assertion failure, and uses the Abort/Retry/Ignore buttons to get the three possibilities.
While this is perfectly usable, we have Builder at our beck and call, and of course, a VCL form can be custom tailored to our needs. The source code for this article includes a TRichEdit control, and formats the assertion error quite vibrantly. The demo program allows you to fire assertions, and try the options. One caveat about the VCL version – avoid using it to check items in other form’s constructors.
Conclusion
Assertions are a handy way of ensured code is acting the way you expect, without adding excessive code bloat. These options provide addition features you should find quite useful, expanding the ways of using assertions.
