>But you can't do this. The pointer points to a memory adress. What stored there looks OK, it's valid. Only the memory area is not allocated by the application anymore. Checking for invalid pointers causes a real overhead here, makes a C++ programm as slow as VFP in these areas.

Then I misunderstood your statement. How would assert() help here where other runtime code would not?

>ASSERT helps you to find bugs during testing, nothing more. Error handler are used for several things: There main purpose is to catch unexpected errors, or things you can't handle in a different way without too much effort, like out of diskspace message, uniqueness violated errors, etc. And they react on program errors by shutting down the application to prevent data loss. Though, I'd call those exception handler.

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

>That's theory. In practice your application has got bugs that you haven't dicovered during testing. To handle these bugs you use defensive programming. There's a relation between defensive and slow programs. The more defensive a program is written, the slower it is. Therefore, you decide what is necessary and what is not necessary.

>Those bugs you catch this way can either be handled directly in the application (for example by using default values)

If the default value is not what was passed in, that will most likely cause incorrect program behavior. I'm leery of "defensive coding," since I believe it hides errors in the release version. Whether it's better to hide them or have the program crash or abort must be handled on a case by case basis.

>In theory, of course, you would handle all assumptions you made with defensive code. In practice it's just not possible, like it's currently not possible to write 100% bug-free aplications. ASSERT is a good compromise here. It doesn't cost speed at runtime, but it catches bugs at the development stage.

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.

>If you tested it, you reviewed the code, you had 100% coverage, and so on, you assume the code is bug-free, otherwise you wouldn't release it, right?

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

>>I think using ASSERT implies a statistical decision: I could have bug X during development, but I probably won't have it in the release version. This seems like a dangerous attitude to me.
>
>No, ASSERT is used for illegal conditions that should never be true, not for real errors.

I'm simply talking about bugs. Bugs are illegal conditions that should never be true, by definition. I don't believe that they can never happen.

In Writing Solid Code Steve MacGuire writes:
>
>"You want both behaviors, but in different versions of your program. YOu want the debug version to alert you to the bug, and you want the ship version to recover safely, with no loss od data. The solution is to write your code using defensive programming the way you always have but use an assertion to alert you if things go haywire" (p. 32)

I think this makes sense. But it's not how most people use ASSERT.

>When you are trying to cover both within the error handler you still have both concepts. And why not just use the built-in functionality, instead of writing your own asserting mechanism?

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

Maybe it would be better if we talked about a concrete example:

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.

What I'm suggesting is instead of (rather lazily) using ASSERT, that we replace it with something like this:

if !ValidateNumber(lnAmt, ">= 0")
// only gets here in release version, in which case we decide whether we should abort,
// use a default value (like 0), notify the user, etc., etc., based on the specific
// situation

which would function just like ASSERT during development, but wouldn't produce erroneous results in the release version. What do you think?