On 02/15/10 10:16, Stephan Bergmann wrote:
On 02/12/10 17:18, Christian Lippka wrote:
If you change code at one place, you may cause an assertion to
trigger at another place.
Since triggered assertions indicate programming errors, the above
sentence is equivalent to "If you change code at one place, you may
introduce a programming error, the symptoms of which can be witnessed at
another place." One reportedly effective measure against such errors is
testing. I think we all know that we need lots of tests, regularly run
(with the average developer in the driver's seat, passionately writing
and executing tests). The test cleanup project wants to improve things
here, and it is by deliberation that the assertion cleanup issue has a
later target than test cleanup.
But unlike compiler warnings there
is no way to check the complete office for assertion automaticly.
Therefore assertions will pop up in the master and annoy others,
causing sooner or later that all people use only pro again. FAIL.
Not necessarily. The point is that triggered assertions need to be
sufficiently rare. Just like people tolerate the occasional master
build breaker, addressed promptly by a masterfix (which you can easily
pull into your affected CWS), I would argue that they would also
tolerate the occasional assertion abort---fixed promptly by a masterfix,
too.
The important point, of course, is that we first need to reach a plateau
where triggered assertions *are* sufficiently rare. We need to address
the false assertions that do not diagnose programming errors (that the
program cannot handle) but rather interesting events (that the program
must handle). We need to have sufficient testing in place so that no
CWS or MWS can any longer introduce triggered assertions on well-visited
code paths.
Therefore assertions will and do pop up in the master. which is
no problem if they get fixed in time. If there is a milestone
that has to many assertions, you can already redirect them
in a window (right after you wrote the author of that assertion
a P1 issue).
This I see differently. First, I believe in the principle of no broken
windows. As soon as you tolerate a single ("harmless") triggered
assertion (which people can oh so easily work around by clicking it away
or redirecting it) you are on your way down the slippery slope. We are
already pretty much at the bottom of that hill; once we are at the top,
we must make sure to stay there.
Second, in an environment where assertions regularly trigger, automated
processes *do* have a hard time coping with them. Automated tests need
to have extra complexity to "hide" assertions, Ause manually needs to
unlock feedme builds that got stuck with a triggered assertion window
from one of the build tools, etc.
If this is still not understandable, I will draw you a flow chart
on monday at your office :-)
Christian, rather than becoming primitive, I would like to ask you the
same question I already asked Frank: "[A]ssuming we have somehow
reached that land [where assertions trigger rarely, and if they do
indicate true programming errors], would you then still have objections
against aborting assertions?"
I have an objection against aborting assertions also in that case. If
you make the pressure on assertions that high, you will not necessarily
get a better code quality. In contrast the result could be that people
will simply stop using assertions. That would be a pity and a great loss
of information!
Ingrid
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
