> This is one of the QA nightmare scenarios:
>
> QA: Hey, we found a bug in the release bits. Here's the repro.
> Dev: Sorry, can't reproduce your error, I hit an assert as expected.
> QA: So test the release version!
> Dev: Uhuh. We don't do that.
The solution to this is simple. Assertion failures are product failures.
If an assertion failure occurs, the offending code is broken, and must be
fixed. The assertion must be analyzed, and if it is found to be bogus (the
condition can legitimately be false), then the assertion must be removed, or
it must take into account the legitimate false condition.
If the assertion is found to be valid, and the assertion fails, then the
developer *must* fix the code. If a developer on my team said to me "I hit
an assert as expected", then I would fire (or re-educate) that developer.
I am of the mindset that assertions should be used to catch serious, fatal
flaws in flow control, data structure integrity, etc. A failed assertion
means the product has gone completely off the rails. It is not a short-cut
for a breakpoint.
-- arlie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 21 19:45:15 2006