On 02/12/10 15:05, bjoern michaelsen - Sun Microsystems - Hamburg
Germany wrote:
On Fri, 12 Feb 2010 14:38:18 +0100
Philipp Lohmann <philipp.lohm...@sun.com> 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).
- 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.
I also cannot see any benefit in having both DBG_ASSERT and OSL_ASSERT.
So +1 for that cleanup.
But still after reading the whole thread I do not understand why an
assertion should abort at all. Assertions are for informations. A
non-informal aborting assertion mixes up concepts in my opinion.
For a place where you would place the suggested OSL_ASSERT_ABORT I would
suggest to place a normal assertion and in addition throw an exception.
The exception should be normal product code, if you know that the
reached state is that bad.
I (as many other developers I believe) use assertions for all those
places where I expect things to be a certain way. In case the
expectations are not met the willing listener is informed about a
potential problem.
We have quite nice tooling for our assertions. If there are too many,
you can pipe them all in a window and check them later for new
introduced ones. So even many assertions occuring is no reason to not
use a non pro build.
-1 for assertions to abort
+1 for developers to use non-pros (though one must be allowed to use pro
builds for performance relevant work of course)
+1 for assertion bugs getting a higher priority
+1 for providing non pro builds during release branch
+1 for cleaning up DBG_ASSERT and OSL_ASSERT
Ingrid
BR,
Bjoern
---------------------------------------------------------------------
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
