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