Assert, SET ASSERTS, Set(“Asserts”)

This cool command lets you test conditions during development, such as verifying proper parameters sent to a function, without slowing down the runtime behavior of your application.

Usage

ASSERT lCondition [ MESSAGE cMessage ]
SET ASSERTS ON | OFF
lAreWeAsserting = SET("ASSERTS")

Assertions have been available in some languages for a long time. One of the most persuasive arguments for using assertions is in the wonderful book Code Complete (see bibliography), and we were pleased to see this addition to version 5.0. Assertions let you test situations during development without bogging down the runtime environment with a lot of testing. The idea is that your Quality Assurance process should catch these situations. Using assertions is equivalent to setting a global “glTesting” variable and then having blocks of code run only if glTesting is true. But another nice feature of assertions is that you don’t have to worry about forgetting to turn them off! A note of caution here: because ASSERTs are tested only during development, conditions that could occur in the runtime environment (such as validating user-supplied parameters) still need to be tested the old-fashioned way.

When the assertion expression evaluates to .F., a dialog box pops up with your optional message (or a generic message citing the line number and name of the program containing the failed assertion) and presents these options: Debug, Cancel, Ignore or Ignore All. Debug suspends the application and brings the debugging windows forward. Cancel halts program execution. Ignore allows the procedure to continue. Ignore All both continues the procedure and SETs ASSERTS OFF until it is set ON again programmatically.

SET(“ASSERTS”) returns .T. at runtime if SET ASSERTS is ON, but assertions aren’t tested, and users don’t see the assertion-failure dialog box.

Example

ASSERT VARTYPE(toParameter) = "O" MESSAGE "Procedure " + ;
         PROGRAM() + " did not" + " get object parameter."

See Also

Debug