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

Yes, I'm using the term "error handler" in a more generic way, as something you would have to call explicitly (just like ASSERT, in fact, but more user-friendly).

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

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

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.

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

This implies that it's impossible to misspell the name of a class in code that's released to the customer. I agree that this should be far rarer than doing it during development, but surely it's not impossible? Testing, while necessary, cannot be relied upon to catch all bugs.

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.