Hi Mark,

>I'm just suggesting that assert() in that case be replaced with code that does the right thing in the release version.

But you can't do this always. Everybody complains about the little speed of VFP compared to C++, but this would slow down C++ to that point. Excel for example has got two calculation engines in the debug version, one that is fast and is used in the shipped version as well, and one that's really slow, but easier written and less risky to bugs. If Excel would use the slow one in the ship version, no-one would use Excel. Even if there might be less bugs.

>But assertions aren't fired in the release version. Therefore if you rely on asserts (rather than backing them up with runtime checks, too), you'll still end up hiding errors.

Sorry, I use assertions as well as defensive programming. Assertion to find bugs quickly, defensive programming to avoid data loss and instable programs.

>I know. :) And don't get me wrong: I think assertions are much better than no checking at all. I'm just saying that I think we need to move to an even higher level, where things are checked in the release version as well as in the development version.

Hey, before we go on to the next level, let's programmer get used to ASSERTs before. :)

>You can't test every single path of the entire program as a whole. You can't test every possible combination of values and calls. That's why I say you can't say an app has no bugs simply by testing it.

But that's not what coverage is about. 100% coverage means that every line of code has been executed, and that gaol can be reached.

>No, that's true. I've just seen so much code where the programmer throws in ASSERTs and thinks she's really protected against bugs. She hasn't, because as soon as she ships that program, none of that checking occurs.

Then we have to train these programmers. :)

>Well, it seems better, in general, to do things once than twice, doesn't it?

Right. Double safety. *s*


>> Assert ASSERT_FOXTOOLS
>> If not (ASSERT_FOXTOOLS)
>> Set Library to (FullPath("FoxTools.Fll")) Additive
>> Assert ASSERT_FOXTOOLS
>> Endif
>
>I like that, except that I don't understand the second ASSERT. It can never fire.

Sure it can, when loading the library was not possible during testing.

Christof