Using the Debugassert Method

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

FIGURE 18.16

An assertion failure

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 shows what the result of an assertion failure looks like in the debugging environment.

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.

Was this article helpful?

0 0

Post a comment