Am 12.02.2010 15:05, schrieb bjoern michaelsen - Sun Microsystems -
Hamburg Germany:
On Fri, 12 Feb 2010 14:38:18 +0100
Philipp Lohmann<[email protected]> wrote:
The obvious optimization for that process would be leaving things as
they are and introduce an OSL_ASSERT_ABORT for those who really want
that.
still one would need:
- to get rid of DBG_ASSERT, because it makes absolutely no sense to
have both DBG_ASSERT and OSL_ASSERT).
Thats a given, you have spare time your manager does not know about?
- to move all the non-informal assertions up to OSL_ASSERT_ABORT. And
Frank and Christian should be the first to do that for their
assertions, if those are, as they claim, only reporting seriously
messed up internal state unlike those chatty noncritical
observations us other devs seem to use assertions for.
If we make the office crash in non pro than there will be never a
chance to get the qa to work on non pro again. By the way as
said earlier, qa used to look at non pro all the time for years.
Then at some point in time the vcl based auto tests got so slow
on non pro, the qa stoped using non pro.
Also, an assertion that aborts hinders my work with the office
as long as the assertion is not fixed. One abort assertion in writer
with 100 people working on the writer causes one to fix the issue and 99
to idle until he has finished and commited the fix. If you like your
assertions to abort, you can press the cancel button. I remember times
before we introduced cws handling where we had developer masters
which would not be usable because of crashes. I'm not eager to go
back to those times.
Also again, assertions are good to have, if an assertion fires, thats
bad. And not only if this assertion is implemented by Frank or me.
If you have a function that accepts integer values from 0 to 100
as a parameter and you get a -1, thats an assertion, not a trace!
If your function is a real time killer if the caller does not
sort the array he gives you beforehand, thats an assertion, not a trace!
If the xml filter reads customer data from an xml file and can not
find the property at the model to set it, thats an assertion, not
something to log!
Maybe we all should put away our modern and cool scrum books for a while
and re read some boring and old fashioned coding principles 1&1 from the
past...
Regards,
Christian
PS: I'm hopefully not to sarcastic on this issue, but its hard to
be calm on an issue that we discuss once a year with the same arguments
and the same outcome :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
