Hi Mark,

>No, I don't think so. I've been using ASSERTs for 15 years.

OK, then I have misinterpreted your message. But the number of years is no explanation. *bg*

>However, one day someone asked why we would check for certain errors during development but ignore those errors in the release version, and I couldn't think of an answer.

Because assertions are used for different things. They are especially usefull to integrate code written by other developers. They verify that the integration is OK, after that you don't have to verify it again all the time.

>It's the "in theory" part that troubles me. :)

Well, we're programmers. :) Of course there are no bugs in my code! *g*

>OK, I can see that. During development, you just want the program to die in its tracks (or patch it up interactively). On release, you'll try to recover more gracefully. However, I doubt most users of ASSERT do this double checking. And it seems to me that you could do better by having one error routine that does different things in development and release, rather than checking every condition twice.

No, no! An error handler and ASSERT do _completely_ different things. An error handler jumps in when there was an error, ASSERT when an assertion failed. It could be that a method can handle a situation without any problems, but it's still a bug that has to be fixed. Unless you call the error handler explicitely it usual jumps too late, when there has already been a situation that is not fixable. It might even be that the part where the error occurs seems not to be related with the actual error. Just assume you release a block of memory in C and afterwards you access that pointer. It works, most of the times, but it might fail in some routine that's far from the original bug. By using an assertion during development and add a system to keep track of those pointers, you can find those errors right where they are caused.

OK, an example. Assume you have a method that receives a class name and a class library. These values are constant. NewObject() fails, if it can't find either the class library, the class or the obejct returns .F. in the Init/Load event. YOu don't have to verify every time that the object reference is a valid object. If it suceeds once, it suceeds everytime (assuming returning .F. doesn't depend on the environment). If it doesn't during runtime, probably the APP is damaged or you don't have sufficient memory, in both cases you can't even shut down gracefully. But during development you might realize that the ASSERT fires, because, for example, you misspelled the name of the class, or didn't include the library into the project. In that case you need an ASSERT only during development, not during runtime.

Christof