Content-Type: multipart/signed;
Content-Transfer-Encoding: 7bit

Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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.

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=20
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=20
configure script doesn't set it on by default, but it does have the=20
-no-exceptions ..... Disable exceptions on platforms that support it.
* -exceptions ........ Enable exceptions on platforms that support it.

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=20
problems for you later.

>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=20
catch bad allocations. One such case is demarshalling a QDataStream.

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=20
serious problem already. That's the consensus we've reached in this list=20
and in kde-core-devel a few years ago.

Does anyone know if the stack unwinder requires memory to be allocated in=20
order to run?
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

2. T=F3 cennan his weorc gearu, ymbe se circolwyrde, wear=F0 se c=E6gbord a=
nd se=20
leohtspeccabord, and =FEa m=FDs c=F3mon lator. On =FEone d=E6g, he hine res=

Content-Type: application/pgp-signature

Version: GnuPG v1.4.0 (GNU/Linux)



Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<