On 02/12/10 13:38, Christian Lippka wrote:
Am 12.02.2010 13:28, schrieb Stephan Bergmann:
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.
No I ment you change something in the code which causes an assertion to
fire.
???
Stopping people from "chang[ing] something in the code which causes an
assertion to fire" (in other words: stopping people from introducing
programming errors) would be great, no? What am I missing?
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
