Hi Mark,

>How would assert() help here where other runtime code would not?

assert() in combination with a lot of extra code. Whenever you allocate memory, the debug version would save this memory adress in a list, when you release it memeory is filled with some value like 0xCC or 0xA3 and the adress is removed from the list. WIth this list you can write a function that validates a pointer, like

assert( IsValidPointer(pPointer) );

>And what I'm saying is that you should also find bugs on release, too, not just during testing.

Sure, bugs are found in the release version by the user and verified in the release version. Then they are tracked in the debug version, and that's where ASSERT are used again.

>If the default value is not what was passed in, that will most likely cause incorrect program behavior.

In that case you have to shut down the application.

>I'm leery of "defensive coding," since I believe it hides errors in the release version.

Exactly my opinion. That's why I use assertions here.

>It is certainly possible to replace every ASSERT with a more robust and user-friendly bug-handling mechanism (see below). That this is not done is a compromise, absolutely. What I'm questioning is whether it's a reasonable compromise.

In my code assertions are way more strict then they have to be, because I like to find as much bugs as possible and not rely on my defensive code to have the application work properly. During testing there's no problem if the application shuts down, reports an eror or crashes whenever it supposes a bug, no matter how small. But at runtime, the defensive code should keep the application in a stable state at least allowing the user to shut down the application properly and save everything they worked on.

>True 100% coverage is impossible. You can't rest every possible execution path. We must not rely on testing (and that's why you use defensive coding).

You can't test any combination of those paths, but you can test every single path.

>But it's not how most people use ASSERT.

That's a different issue. But this doesn't mean that ASSERT is useless itself.

>Because then, as Jim says, you have to handle the test twice: once in an ASSERT, and again in the defense.

Exactly. And what's wrong with that?

>proc UpdateTotal(lnAmt)
>
>Assert lnAmt >= 0
>
>this.total = this.total + lnAmt
>
>endproc
>
>This is the kind of ASSERT I'm talking about. The programmer writes this, and the ASSERT catches invalid negative entries. By so doing, she is saying, whether she knows it or not, that lnAmt can never be negative in the release version. I simply think that statement can't be shown to be true.

I agree. That's why you need defensive programming as well. Lemme show you an example, how I'd use ASSERT:

   Assert ASSERT_FOXTOOLS
   If not (ASSERT_FOXTOOLS)
      Set Library to (FullPath("FoxTools.Fll")) Additive
      Assert ASSERT_FOXTOOLS
   Endif

ASSERT_FOXTOOLS is a define that verifies that FoxTools.FLL is loaded, that's done by testing Type("_WMainWind()") == "N". This method needs a function in FoxTools. Therefore it asserts that FoxTools is loaded. When I'd forgot to load FOxTools I'm notfied during testing and can include it. Nevertheless it tries to load FoxTools.Fll. If that doesn't suceed, for example because FoxTools.FLL is not available, another assertion pops up. In the runtime version, the library is silently loaded. Of course I could add some more code here to quit the application, if that failed, but I considered it safe to rely on the "programm xxx.PRG not found" error that will occur later on.

I think that's similar to your approach, just that I use ASSERT here.

Christof