[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: C++ exceptions
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2005-12-07 13:19:05
Message-ID: 200512071419.05606.l.lunak () suse ! cz
[Download RAW message or body]

On Wednesday 07 December 2005 13:54, Thiago Macieira wrote:
> Volker Lukas wrote:
> >Thiago Macieira wrote:
> >> [...]
> >>
> >> Allowing the exception to reach the Qt signal/slot mechanism is bound
> >> to fail and, quite possibly, core dump.
> >
> >This does not seem to be true. There is no place in the Qt documentation
> >which forbids this (or at least no prominent one), and Trolltech
> > actually treats problems which arise in the situation you described as
> > bugs. So while letting exceptions leave a slot or event-handler might
> > not be recommended practice, Qt is at least intended to work correct in
> > that case.
>
> That's true if the library was built with exceptions enabled.

 Not quite, just compiling some code with exceptions enabled doesn't mean it 
will actually work, as the code may not be exceptions-safe. If one gets 
unlucky it may be even wrong functionality instead of just resource leaks.

>
> Since it doesn't use exceptions for itself (except as a result of operator
> new), it can be built with -fno-exceptions. And in that case, letting
> exceptions propagate into the library will probably cause core dumps.
>
> What I don't know is if it's recommended to use -fno-exceptions. The Qt
> configure script doesn't set it on by default, but it does have the
> option:
>     -no-exceptions ..... Disable exceptions on platforms that support it.
>  *  -exceptions ........ Enable exceptions on platforms that support it.

 And configure also contains this and prints it if you don't use 
-no-exceptions:
        This target is using the GNU C++ compiler ($PLATFORM).

        Recent versions of this compiler automatically include code for
        exceptions, which increase both the size of the Qt library and the
        amount of memory taken by your applications.

        You may choose to re-run `basename $0` with the -no-exceptions
        option to compile Qt without exceptions. This is completely binary
        compatible, and existing applications should continue to work.

>
> So, my recommendation stays: do not let exceptions propagate to inside the
> Qt libraries and, even more so, the KDE libraries. Doing so could cause
> problems for you later.

 Right.

>
> >Qt does use exceptions. It might not contain many throw-statements, but
> > it uses the throwing forms of "new", and it lets exceptions (from new
> > or from user code) propagate out of the library.
>
> True. And I think all those "new" that allocate memory that is potentially
> large should either be in a try/catch block or use new(nothrow) so as to
> catch bad allocations. One such case is demarshalling a QDataStream.

 That still may not actually help that much with memory overcommitting.

>
> Those normal "new", allocating memory for objects, don't need to check for
> the result or exception being thrown. If that happens, the user is in
> serious problem already. That's the consensus we've reached in this list
> and in kde-core-devel a few years ago.

 Right.

>
> Does anyone know if the stack unwinder requires memory to be allocated in
> order to run?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]