Christian Lippka wrote, On 02/12/10 12:34: > Assertions are the first, cheapest and easiest way of defense in the > fight for software quality. > > My 2c, assertions must not abort, developer must use non pro builds, > assertions should be used in every new peace of code.
I fully agree. -1 for assertions to abort +1 for developers to use non-pros -1 for discussing here whether or not QA should use non-pros, because it IMHO has absolutely no influence on how assertions should behave. And if you want QA to use non-pros, they for sure would give up quite soon when assertions always abort. Malte. Christian Lippka wrote, On 02/12/10 12:34: > Am 12.02.2010 12:05, schrieb bjoern michaelsen - Sun Microsystems - > Hamburg Germany: >> On Fri, 12 Feb 2010 09:11:21 +0100 >> "Frank Schoenheit, Sun Microsystems Germany"<[email protected]> >> wrote: >> >>> - Developers should use non-product builds *only*. That's a very >>> apparent measure, still, a lot of people don't do. If you ask why, >>> often the answer is "it's unusable 'cause of the many assertions". >>> Hmm? >> I am one of the devs that rarely use a non-pro build, but not because >> "it's unusable 'cause of the many assertions", but because there are >> simply to many differences from the product build in them, causing >> issues (first of all: annoying build breakers). I do, however build >> with DEBUG=true to see assertions. > So you see OSL_ASSERTS from your code, but you never see asserts from > code that your code uses. Or things you break with your code in other > places. > Can you elaborate on the issues that bother you? > And I may be wrong but DEBUG=true in pro does not give DBG_ASSERTs. > >> On the topic of "what is an assertion": Yes, assertions should abort. >> Otherwise, they are not an assertion, but something that is better >> covered by OSL_TRACE. > Assertions are different to build breakers enforced by the changes for > warning free code. You can very easy verify that you have not introduced > any compiler warning with your changing by simply build the complete > office (yes not 100% I know, but you can be very sure). > > 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. > > Assertions are the first, cheapest and easiest way of defense in the > fight for software quality. > > My 2c, assertions must not abort, developer must use non pro builds, > assertions should be used in every new peace of code. > > Regards, > Christian (using non pro builds for his daily work since 1999) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
