Hi Bjoern,

> - to get rid of DBG_ASSERT, because it makes absolutely no sense to
>   have both DBG_ASSERT and OSL_ASSERT).

Welcome to the "How should our diagnostics system look like" discussion.
I think we started that topic at least three times in the last 4 years :)

> - 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.

Hmm, seems I expressed myself wrong somewhere.

I never claimed that my assertions are so serious that they should be
aborts. I claimed that the assertions I write point to a bug, if they
fire. However, I try my very best all the time to nonetheless gracefully
handle the situation, to let the user continue her work, even if not
everything went as expected, internally.

So, this kind of assertions are no traces, since if they fire, they
indicate a bug. Nonetheless, they (usually) should not abort ... (more
on this below)



For the "diagnostics system", and how it could look like:

I strongly agree that having two systems is weird, and they should be
unified. This was consensus everytime we discussed this in the past.

Also, I am fine with introducing assertions which abort when they fail.
Though, I believe they should be used with extreme caution only. There's
a reason why we spent *so much* time with crash reports, and fixing
crashes: In the user's perception, a crash/abort is one of the worst
things which can happen. I'd claim that we, as developers, usually have
more options than "abort", which can lead to a much better user experience.

Ciao
Frank
-- 
- Frank Schönheit, Software Engineer         frank.schoenh...@sun.com -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Reply via email to