As seen in previous sections in this chapter, you can cause your code to enter
Break mode in various ways. With the exception of the
Stop
statement, however, none of the automated techniques previously discussed
(toggling a breakpoint or setting a Watch expression whose type is Break When
Value Changes or Break When Expression Is True) can be stored between sessions
of your VB development environment. The Watch expressions or breakpoints you set
up during a VB development session are lost as soon as you exit VB or exit the
VB project.
The Debug.Assert method enables you to save breakpoints
and break conditions with your code so that they persist from one development
session to the next.
Debug.Assert causes your code to enter Break mode
at design time if a specified condition is False.
The format for a call to Debug.Assert in your code
is this:
Debug.Assert logical condition
where logical condition is any expression that evaluates to a True or False
value. For instance, if you wanted your application to enter Break mode whenever
the variable intEmployees were 0, you would write the
line:
Debug.Assert intEmployees <> 0
In other words, you are asserting that intEmployees is
not 0. If it is, the Assert method forces the application to enter Break mode.
What if you always wanted your application to enter Break mode at a particular
point, regardless of conditions? The line
Debug.Assert False
would do the trick, because False is, of course, always false. Like the Debug.Print
method, Debug.Assert has no effect when the compiled
executable file runs. This means that you can also permanently leave
Debug.Assert statements in your production code without any problems for
your executable file.
Figure 18.16 shows what the result of an assertion failure looks like in the
debugging environment.
FIGURE 18.16 An assertion failure.
Notice how the code executed normally until it reached the
Debug.Assert line. The expression "i = 10"
evaluates as False, because i has just been
declared and VB initializes Integer variables to 0 by default. Because this expression
is False, the Debug.Assert on
this line caused the application to enter Break mode. The line with the assertion
is highlighted, and an arrow immediately to the left of the assertion indicates
the program is still running, but execution is suspended at the indicated line.
So far, this discussion has focused on the mechanics of the
Assert method, but has not said much about when to use them. Consider using
an assertion whenever your code depends on an expression satisfying certain criteria.
If you have already gone to great lengths to ensure that your code is trouble
free, why not take an extra step to verify that you haven’t let something
slip through the cracks? Even after you have applied every reasonable test that
you can imagine, an assertion may lead you to some things you had not imagined.
If you plug the expression into an assertion only to trigger an assertion failure,
maybe your original tests weren’t as good as you thought.
By alerting you to conditions that are contrary to your expectations, assertions
help you to create tests that more completely reflect the actual conditions under
which your code must perform. When you trigger an assertion failure, you know
at once that your assumption is wrong, meaning that you must either do something
to ensure that it continues to be valid or reframe the assumption.
Generally speaking, it is a good idea to get into the habit of using assertions.
Remember, however, that an assertion is not a substitute for an error handler.
It can show you where there may be a problem, but an assertion can’t resolve
any problems in your code at runtime because it isn’t part of the compiled
program.
