[Development] Exceptions

[Thiago Macieira]

On Wednesday 22 May 2024 06:38:28 GMT-3 Volker Hilsheimer via Development 
wrote:
> As long as Qt is built with exception support

We don't support toggling that on and off any more and haven't for a while.

QtCore and QtGui are compiled with exceptions enabled; all the other modules 
are not. In paticular, QtWidgets is not and that therefore applies to 
QApplication::notify(). That means you MUST NOT let exceptions run through the 
event loop of a Widgets application.

You shouldn't let it happen for any application because Bad Things Will 
Happen™ because we don't test what happens if you do. Your very best bet is 
that you end up back in main() where you can do an emergency save using non-Qt 
code and terminate the application. But since we don't test, we can't 
guarantee that even the exceptions-enabled code in QtCore and QtGui won't just 
crash because of some unsuspected condition being violated.

> There might be code paths (esp on macOS) that go into the native functions
> and back into Qt, and perhaps some of those native stack frames eat the
> exception or don’t pass it on otherwise.

As far as I understand, the problem is that on ARM, there *is* no native stack 
frame, unlike on x86. Stack unwinding on x86 is very frequently possible 
because the architecture saves the return address on the stack and most code 
is compiled with frame pointers, even when exceptions are disabled. On ARM and 
other RISC architectures, the return address is saved in a register and it's 
the responsibility of the prologue of the called function to save it somewhere 
in the stack if it is not a leaf function. The problem is answering: where?

This requires reading the unwind information.

Which isn't present in QtWidgets.

That explains why Dennis reports being able to throw through 
QApplication::notify() on Intel Macs but not on ARM Macs.

Plus, yes, we often have frames from third party libraries in our stack that 
aren't capable of unwinding the stack either. Therefore, the Qt recommendation 
is that you treat all event handlers and all slot invocations as noexcept and 
catch your own exceptions before they go back to Qt code. This is the reason 
why we decided it was ok to disable exceptions in QtWidgets itself, because we 
didn't think we could guarantee survivability in the first place.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Fleet Engineering and Quality
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240522/3d73077a/attachment.bin>