Hi Sylvain,

>I recently aquired Visual Studio 6 and I bought a copy of FoxPro Advisor with that (October issue).
>
>In his article about the report-wrapper class (p.41 to 49), Chistof Lange uses the ASSERT command (like ASSERT TYPE("tcOption") == "C").
>
>I fail to see what this command does, and VFP's help isn't helping...
>
>Anyone care to elaborate?

ASSERT is a very powerfull debugging tool that has been introduced in VFP 5. It is only executed when you run a program in the development environment, the runtime library of VFP skips this command.

ASSERT evaluates the expression and if it's .F., it will display a message. By default it's "Assertion failed on line xxxx in module yyyy", but you can add a MESSAGE clause to display your own message. WIth this command you can verify certain assumptions you made in the code. For example I expect the tcOption parameter to be a character. If it's, let's say, numeric, the method will cause an error a couple of lines later.

In real application I use it even more than in the code in the article. For example CREATEOBJECT() is followed by an assertion to verify that the object is indeed an object, if a method accesses a table I verify that the table is used, if only certain values are possible, I assert that the string only contains these values, if the method can't really deal with NULL values, I assert that they are not NULL, and so on.

Often this is followed by some defensive programming code that uses default values for parameters that are wrong, or exit the method with an error code. So why use ASSERT, if it's checked anyway and it doesn't work at runtime?

There are two important reasons. First, you make clear to anyone reading or maintaining the code what assumptions you made. It's not buried in the code somewhere, but you can see right from the beginning that the parameter must be a string. Second, you find errors as early as possible. Passing a wrong parameter doesn't always cause an error immediately, a method might succeed, but with undefined results, or you get the error in a method you called from the method that actually caused that error. Having an assertion makes it easy to locate an error.

And I'm a framework developer, many developers are using my code. Assertions help them to use my code properly. If the pass a wrong parameter, haven't loaded a necessary library (that's asserted in my code as well) they are informed.

ASSERT is a debugging tool, no error handling tool. It supports you during development, but you still have to write an error handler to deal with errors that happen at runtime.

Christof