Hi Mark,

>But if you don't check for invalid pointers in the release version, your program could crash.

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.

>You (and others) have said that ASSERT and an error handler are used for two different things. I don't think so. I think they are used for exactly the same thing: to catch bugs (error handler also catch other exceptions). The real difference is what they do when they catch them.

No. *s*

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.

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) or they call the error handler in some way. All others will either result in wrong program behaviour or errors that are caused by the bug (like "oRef is not an object" errors when CreateObject() failed).

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.

>This implies that it's impossible to misspell the name of a class in code that's released to the customer.

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?

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

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?

Christof