Hi Bjoern,
> With assertions being assertions and "give up" meaning reporting it,
> thats exactly the desired behavior.
>
> Current situation:
> - assertions might be anything from a informal "I didnt expect this
> external data" to a critical "internal state corrupt"
>
> Desired situation:
> - assertions are only "internal state corrupt" messages and should
> abort
> - everything else is tracing, logging
I'm somewhat unlucky with the terms "tracing" and "logging" ...
I don't want this to be a mere "trace" here: Tracing is used for "Oh, by
the way, user just selected Font X into Device Y", and stuff like that
(try enabling traces in the Ctrl-Shift-Alt-Dialog to see what I mean).
Tracing is *merely* informational, and usually carrying information
which is useful for following the program flow without a debugger. This
is what I would define as tracing.
With this, an OSL_ENSURE is not "tracing", it is an error report: At the
moment of the writing the context, it was assumed some condition is
always true. Over time, as the context evolved, this was violated -
reporting this violation surely is not "tracing" or "logging".
(Whether or not one should try to gracefully handle the violation is
exactly the question which is good for some more religious wars.)
I had hope that we would not need to start the whole discussion about
the diagnostics system, again, but it seems it might be necessary before
finding consensus ... (and finally, perhaps it's good for something)
So, in my opinion we would need 3 levels, at least, not 2:
(1) traces (today: OSL_TRACE, DBG_TRACE)
(2) error reports (today: DBG_ERROR, DBG_ASSERT, OSL_ENSURE, OSL_ASSERT,
OSL_PRECOND, OSL_POSTCOND, and more)
(3) error reports which the program does not survive, in particular in
a product build, i.e. at the customer's machine
(future: OSL_ASSERT_ABORT?)
Whether or not (2) should abort in non-product builds - well, multiple
people here said that they think that this would undermine the
acceptance of non-product builds, both for developers, and for users
brave enough to test developer snapshots as non-product builds.
Ciao
Frank
--
- Frank Schönheit, Software Engineer [email protected] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
