> On 22 May 2024, at 16:30, Volker Hilsheimer via Development > <development@qt-project.org> wrote: > >> On 22 May 2024, at 13:20, Turtle Creek Software <supp...@turtlesoft.com> >> wrote: >> >> When we posted this problem to the Interest list, Thiago replied that Qt is >> not designed to pass along exceptions and we shouldn't rely on the override >> to QApplication::notify. He later qualified that some parts of Qt should be >> exception-safe but QWidget etc are not. > > Taking a deeper look at this, the TL;DR is that on ARM ABI, a function > compiled without exception support will result in std::terminate being > invoked if an exception is thrown, which invalidates our documentation as > well as your architecture.
[…] PS: the same test on an x86 mac works as one might optimistically expect. Test code attached, build with -fexceptions. > >> Thanks, Dennis >> >> On Wed, May 22, 2024 at 5:38 AM Volker Hilsheimer <volker.hilshei...@qt.io> >> wrote: >> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2019%2Fp0709r4.pdf&data=05%7C02%7Cvolker.hilsheimer%40qt.io%7C464e29a3661847dda24008dc7a6c6236%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638519853156941654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=yx%2Bk90lK5Gi0saviPnC1zLRJx7FNUC4uoAy4fyT6rYI%3D&reserved=0<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
main.cpp
Description: main.cpp
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
