I'm in full agreement with Michael. This is just smart programming.
Michael Phipps wrote:
Assert in applications is *very* different from assert in an OS.
Assert in an application is supposed to be "this shouldn't ever happen, but since I am paranoid, do this". It is frequently (always?)
built as a macro so that it can be compiled out.
In an OS, (or, really, in any library), this is not necessarily favorable behavior. Would you, as an app writer, want your app to *stop* if
the library writer has a bug? Really hard to tell. It might be a bug that
would cause the application to do Bad Things (like send packets to
the wrong address or broadcast them or something). OTOH, stopping
is a good thing for debugging the library - it prevents applications from
working so that a bug can be reported.
We debated this for quite a while in Glass Elevator, under the guise
of exceptions. Asserts are really primitive exceptions for C.
I guess my take on it would be that user input (app writer input, for us) should *NEVER* cause an assertion. No combination of calls, no API interfacing
should cause an assertion. That is what error return codes are for. Assertions
should be reserved for "I am internally screwed up in some way".
As an example. Let's say you had a linked list. Attempting to add a NULL pointer to it should not cause an assertion.
If the linked list realized that it had become circular (this happened to me - it was a multi-threaded issue), that should throw an assertion.
The list didn't lock itself properly, in my case.
This is just MHO. I am open to better ideas on this...
And thanks, Scott, for bringing it up...