[Development] Exceptions

[Thiago Macieira]

On Thursday 23 May 2024 04:07:20 GMT-3 Volker Hilsheimer via Development 
wrote:
> From what I see, the problem is bigger than “don’t let exceptions run
> through the event loop” though. In my example, even a try/catch around
> calling the parent class implementation of QWidget::event will not work,
> because QWidget::event doesn’t have the unwind information.
> 
>     bool event(QEvent *e) override {
>         try {
>             return QWidget::event(e);
>         }
>         catch (const std::runtime_error& e) {
>             qDebug() << "Exception in event()!" << e.what();
>         }
>         return false;
>     }
> 
> 
> In practice, that means that you cannot meaningfully use exceptions in a Qt
> application (or library with possible binary compatibility commitments)
> unless you catch them on the lowest stack frame that is not Qt. Which is
> perhaps not terribly useful.

That's what I said: you should treat all event handlers and slots as noexcept 
and catch your exceptions there.

There's NO reason why clicking a button in a UI should generate 
std::runtime_error. That's always an application bug if it happens, so it 
should be treated as a bug. Crashing with the full throw-point stack frame is 
a good idea.

The contract between signal emitter and slots also has no room for exceptions. 
The connection is N:M and the emitter doesn't care if the slot failed to do 
its work. Therefore, yes, slots should also be noexcept.

In both cases, that assumes when being called from the Qt machinery. If you're 
calling those functions directly, feel free to throw. How you determine the 
situation is left as an exercise to the reader.

I agree on questioning whether this is useful or not. But I also think it's 
besides the point: we are not going to change because of the reasons above.

> So the question is what we want to do about
> https://doc.qt.io/qt-6/exceptionsafety.html. It starts with the disclaimer
> that this is not feature complete, but that’s been the case since the dawn
> of time, and on ARM, even common cases won’t work as advertised here.
> Perhaps a good start would be to add a warning that none of this will work
> on ARM architecture, unless Qt is compiled explicitly with exception
> handling enabled? Which then might ideally be something we support in the
> build system through a toggle.

That definitely needs fixing. At a minimum, the #recovering-from-exceptions 
section is wrong, because we know the exception can't propagate through the 
event loop. 

The #signals-and-slots section is what I said above.

-- 
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/20240523/6246cef8/attachment.bin>