> assert( IsValidPointer(pPointer) );

Which means that if an invalid pointer occurred in the release version, it would not be caught at this point (where perhaps the app could indeed be shut down gracefully), but instead when it was next used. And who knows what state things would be in then?

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

>>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.

But that doesn't happen. The incorrect value is replaced by a "defensive" default value, and the app goes on its merry way.

>>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.

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.

>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.

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.

>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.

I agree with that. That's what's implemented in the sample code I posted.

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

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 it's not how most people use ASSERT.
>
>That's a different issue. But this doesn't mean that ASSERT is useless itself.

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.

>>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?

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

> 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.