Assert the Basic Way


If you assert a lie (for instance, that 2 and 2 is 5) in an MS-DOS C program, your program will terminate and you’ll see output such as this on the command line:

Assertion failed: 2 + 2 == 5, file c:\lies.c, line 6

It would be nice to get similar output from Visual Basic. If you had an assert system like this, your test team could run compiled versions of programs through test suites and get useful error reports when programs failed. You could send compiled programs with asserts to your beta customers. If they exercised code paths not hit by your testers (customers do the darnedest things), you could get useful reports back from them. If you’ve ever been on a beta program for Visual Basic or any other professional program, you know what I’m talking about.


Unfortunately, Debug.Assert won’t help you do this. If the Debug object were based on a CDebug class written in Basic, Assert would look something like this:

‘ CDebug.Cls
Public Sub Assert(fExpression As Boolean)
    If fExpression = False Then Stop
End Sub

Of course, that’s not exactly what Debug.Assert does, because the Debug object disappears in compiled programs. It exists only in the Visual Basic Integrated Development Environment (IDE), which most of your beta customers won’t have. If you wrote your own Assert that looked like the one above, the Stop statement would terminate an EXE program. But since Assert is a method of Debug and Debug doesn’t exist in an EXE or in a DLL or in an OCX, your program won’t stop anywhere except in the debugger.


I hate to say it, but I don’t think Debug.Assert is worth the trouble. Professional programmers need a better system, but when you try to implement one, you’ll run into some of the problems that probably prevented the Visual Basic team from providing a more useful Assert. The problem is that at run time, Visual Basic doesn’t know the text of the expression that failed, and it doesn’t know the file-name and line number, either. The C compiler knows this information through the wonders of a feature called a preprocessor. I’m not going to get into a sticky debate about the value of preprocessors as a language feature. Let’s just say that most languages don’t have one, or at least not a sophisticated one like C’s. Pascal, Java, and Visual Basic are some of the languages that can’t use a preprocessor to do assertions.


Of course Visual Basic does parse the assertion at compile time, and it could theoretically store the expression text, filename, and line at that time for use at run time. Some languages that don’t have preprocessors still manage to provide assertions or equivalent language features. I suspect that one reason Vi­sual Basic doesn’t do so is that it has always been an expression-oriented language. P-code is evaluated as expressions without any reference to line numbers. Most native code compilers report compile errors by line and file number. Maybe there’s a connection. Maybe not. In any case, if you want assertions any place other than the IDE, you’ll have to do them yourself. In other words, write your own preprocessor. That’s what I did.