Hi Dennis, > On 7 May 2024, at 21:05, Turtle Creek Software <supp...@turtlesoft.com> wrote: > > TurtleSoft posted on the Interest list earlier about problems we had with > exception handling, and Thiago suggested I post here. > > Since the early 90s, our C++ code has had about 10,000 sanity checks which > give an error message with source file & line number, then throw an > exception. There is a try/catch block in the event loop which swallows them. > That way users can continue work. Only a small % of the checks are ever > called, but it makes bugs very easy to fix when users or testers report them. > Our app almost never crashes thanks to the many checks. We learned the system > from Bill Atkinson, author of MacPaint and HyperCard. > > The sanity system started in Metrowerks PowerPlant, then worked OK in Carbon, > Cocoa, and MFC. For Qt we wrapped QApplication::notify with try/catch. It > worked for most checks on Macintel and Wintel, but failed for Mac ARM. After > the message, instant termination. Users lose their work, testers must start > over. > > Turns out that Qt intentionally does not support exceptions thrown through > GUI classes, and the early success was just an accident.
Can you elaborate on that point? As long as Qt is built with exception support, exceptions thrown in code that starts in the event loop should reach a QCoreApplication::notify override. 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. And there is code in Qt that catches exceptions thrown in constructors or destructors (including ~QWidget). But in general, Qt shouldn't eat or disable or otherwise handle exceptions deliberately. > Exceptions are an "exceptionally" handy C++ feature. Instant "beam me up, > Scotty". It is too bad that Qt does not support them fully, and I'd like to > change that. So I would be willing to work on getting GUI classes like > QWidget able to pass exceptions, if it means we can get our old > sanity-checking back. It would be our open-source contribution. Sadly, exceptions are perhaps also one of the most poorly designed features of C++. The status quo has resulted in several alternative approaches and strategies and a fragmented way of handling errors in general, which is (still?) subject of discussion in the C++ committee. E.g. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r4.pdf (to be fair, I don’t know if this particular proposal is still on the table; std::expected in C++ 23 is one attempt at unifying error handling at least, but it’s a library rather than a language feature, so not nearly as capable especially for handling truly unexpected situations). > I realize this is a huge, fundamental change to Qt. It would need to be a > multi-year project, done in tiny bits so as not to break things. Anyhow, my > time is limited. > > Getting exceptions through signals/slots is lower priority. We don't use > those much and probably could bypass them somehow. We just want a reliable > path to the event loop. > > Personally, I've programmed since punch card days in 1966 or so. I've > designed and shipped several apps for PCs. I've refactored and rebuilt all > sorts of C++ code from other people, and could do this work politely and > competently. > > Does this seem reasonable? Let’s get to the bottom of the problem you are seeing first. IIRC, we tried to make Qt exception-safe in the Nokia/Symbian-Porting days, but that’s many years ago and those code paths have not gotten much interest in the time since. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
