On 02/12/10 12:34, Christian Lippka wrote:
But you can never be 100% sure that you didn't introduced assertions since you can't check every code path there is that may be affected by your changes. Therefore assertions will pop up in the master and an abort will render non pro unusable so people will stop introducing them.
If with "introducing them" you mean "introducing assertions:" People who write extremely bad code (code that contains programming errors and additionally lacks assertions, that would allow to identify those programming errors more easily) have to be handled in some way, yes. But, if left unhandled, those people will write bad code whether or not assertions abort.
If with "introducing them" you mean "introducing [i.e., using] non-pro builds:" The logic of preferring a pro over a non-pro here, as, upon encountering a programming error the pro carried on regardless (and potentially silently corrupted data, or silently gave wrong results) whereas the non-pro failed fast, looks faulty to me.
Assertions are the first, cheapest and easiest way of defense in the fight for software quality.
Yes. And we have that tool at our disposal, but let in run blunt, so that it is largely unused today.
-Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
