Hello,
I'd like to remove the backtrace printing from OSL_ASSERT and friends, or,
even better and if possible, make these functions work properly, i.e. abort
on failure (I'm not really holding my breath on the second one, but refusing
that one will at least support the first one).
When bui
I fully agree. We need to make it clear what assertions really mean, and how
they should be used. Currently it is somewhat of a disaster area. There are
places in the code that cause "assertion failures" every time the code is run
if built with debug=t. So does that then mean that the code is ac
Lubos Lunak wrote:
> I'd like to remove the backtrace printing from OSL_ASSERT and friends, or,
> even better and if possible, make these functions work properly, i.e. abort
> on failure (I'm not really holding my breath on the second one, but refusing
> that one will at least support the first
On 19/04/11 17:21, Lubos Lunak wrote:
+1 for disabling the backtrace
and yeah, the whole assert thing is pretty bogus but at least lets keep
the information from those asserts ( converted into some warning or
something ) 'cause at least I have gotten some hints to real brokeness
in the past
I just a moment ago came across a nice example how confusing and unclear the
use of the various kinds of assertions can be.
See unotools/source/config/searchopt.cxx , sal_Bool
SvtSearchOptions_Impl::Load():
const Any &rVal = pValues[i];
DBG_ASSERT( rVal.hasValue(), "prop
On Wednesday 20 of April 2011, Thorsten Behrens wrote:
> Lubos Lunak wrote:
> > I'd like to remove the backtrace printing from OSL_ASSERT and friends,
> > or, even better and if possible, make these functions work properly, i.e.
> > abort on failure (I'm not really holding my breath on the second
On Wednesday 20 of April 2011, Tor Lillqvist wrote:
> Another related thing that is broken is how the code often loses useful
> information associated with exceptions.
>
> To take an example, the root cause to much breakage on Windows in the 3.4
> beta1 caused an exception with the nice message "pa
Hi Lubos,
On 2011-04-21 at 17:12 +0200, Lubos Lunak wrote:
> > Then, there's sal-disable-backtrace.diff,
> > which I can happily merge - just set DISABLE_SAL_BACKTRACE then.
>
> Again, it's more about the default being wrong, as in the usual case the
> current default is about spamming the ou
On Friday 22 of April 2011, Jan Holesovsky wrote:
> Hi Lubos,
>
> On 2011-04-21 at 17:12 +0200, Lubos Lunak wrote:
> > > Then, there's sal-disable-backtrace.diff,
> > > which I can happily merge - just set DISABLE_SAL_BACKTRACE then.
> >
> > Again, it's more about the default being wrong, as in th