Re: [Interest] More on Exceptions
On Saturday 25 May 2024 09:51:49 GMT-3 Jean-Michaël Celerier wrote: > Likely there are "bad things" that could theoretically happen but in 10 > years of https://ossia.io across Mac, Windows, Linux and tens of thousands > of exceptions being caught after unwinding through the Qt and QWidget event > handling due to fairly defensive programming strategies (assertions > everywhere being transformed into exceptions in release builds), I have yet > to see *one* of these mysterious corruptions mentioned here. > > The time saved by my users who can however just resume using the software > after a small error popup is immense. Hello Jean-Michaël Do you have experience of this working on ARM Macs? That's the issue that Dennis is having: by default, the compiler there doesn't generate unwind information if exceptions are disabled, unlike on x86. So the big question I asked: does the same apply to the Apple libraries themselves? -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] More on Exceptions
On Saturday 25 May 2024 09:27:54 GMT-3 Turtle Creek Software wrote: > Thiago, I'll describe what happens when our typical exception is thrown, > since conditions are very different from what you describe. > > Before any method uses a pointer, it first does a sanity check. If nullptr > it shows a dialog with file/line number and what failed, then throws an > exception to avoid crashing. There are 7000+ checks, plus another 1000+ > assertions for other bad states. 99% will never be called. Some throws are > caught internally but most go out to the event loop, which has a try/catch > block. What is a user going to do with that information? This is my case of "clicking a button causes std::runtime_exception" - no, this is a UX bug. The user can't affect the result and will confuse the user. You should design your software so this condition will not happen and, in the unexpected case where it does happen, you need to handle it without user interaction. > The app has a couple megabytes of just file/line number text, since it > needs to be compiled in. The original plan was to remove them in release > build, but they help for user bug reports so they're permanent. Users tell > us exactly where to find the problem. You don't need the UI for this. More importantly, you *cannot* trust the process itself to display UI because, by construction, you've run into an unexpected condition because some internal invariant was violated. If you want to display any sort of UI, it needs to be out-of-process. > In practice, 99% of throws are from something trivial/stupid- a missing > field, or a link to something that doesn't need to be linked. They are > caught in the event loop and users can safely continue working. In rare > cases they may see a ton of weird messages and need to force-quit. Then just catch before returning to the event loop, eat the exception, and continue. You don't need to display a dialogue asking the user if they want to continue: they always do. My advice is you do no such thing. If you've run into an unexpected condition, continuing is just going to accumulate errors, postponing the crash until finding out what caused the initial problem is nearly impossible. > As the stack unwinds after a throw, in theory it should tidy everything via > scope endings and destructors. In practice, maybe there are leaks or other > bugs along the way. But in theory, those bugs would show up anyhow when the > stack unwinds from normal use. In practice, the setup has worked well for > 20+ years. Users see helpful error messages rather than crashes. Maybe the > exception throws cause subtle, unknown problems but no worse than the usual > problems in any app. In theory, there are no bugs. In practice, there are. > I think Qt should enable exceptions in QWidget etc by default, strengthen > the disclaimer a bit, and feel no obligation to survive throws in perfect > condition. Pass them along and let developers deal with the consequences. > Exceptions should be for weird problems, and if things get weirder, so > what? Based on our experience in x86 it probably will be just fine. As I said before in the dev mailing list: this is pending someone checking that the Cocoa and Win32 and glib frames that may be in the call stack can be unwound too. If they can't, then the exception unwind info in QtWidgets is dead weight. Even if someone shows they work, we may not do it in the official builds. But you can do it yourself. In fact, since you do have such a good infrastructure for testing whether it works, I recommend you just do it and tell us if it works. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] More on Exceptions
I share a similar experience. Likely there are "bad things" that could theoretically happen but in 10 years of https://ossia.io across Mac, Windows, Linux and tens of thousands of exceptions being caught after unwinding through the Qt and QWidget event handling due to fairly defensive programming strategies (assertions everywhere being transformed into exceptions in release builds), I have yet to see *one* of these mysterious corruptions mentioned here. The time saved by my users who can however just resume using the software after a small error popup is immense. On Sat, 25 May 2024, 08:29 Turtle Creek Software, wrote: > Thiago, I'll describe what happens when our typical exception is thrown, > since conditions are very different from what you describe. > > Before any method uses a pointer, it first does a sanity check. If nullptr > it shows a dialog with file/line number and what failed, then throws an > exception to avoid crashing. There are 7000+ checks, plus another 1000+ > assertions for other bad states. 99% will never be called. Some throws are > caught internally but most go out to the event loop, which has a try/catch > block. > > The app has a couple megabytes of just file/line number text, since it > needs to be compiled in. The original plan was to remove them in release > build, but they help for user bug reports so they're permanent. Users tell > us exactly where to find the problem. > > A few exceptions are fatal and just terminate. The database is never in > unstable state so we can leave safely at any time. Actually it's unstable > briefly during commits but nothing throws in there so the only danger is > power failures. > > There probably are apps that need cleanup on terminate, but ours isn't one. > > In practice, 99% of throws are from something trivial/stupid- a missing > field, or a link to something that doesn't need to be linked. They are > caught in the event loop and users can safely continue working. In rare > cases they may see a ton of weird messages and need to force-quit. > > As the stack unwinds after a throw, in theory it should tidy everything > via scope endings and destructors. In practice, maybe there are leaks or > other bugs along the way. But in theory, those bugs would show up anyhow > when the stack unwinds from normal use. In practice, the setup has worked > well for 20+ years. Users see helpful error messages rather than crashes. > Maybe the exception throws cause subtle, unknown problems but no worse than > the usual problems in any app. > > I think Qt should enable exceptions in QWidget etc by default, strengthen > the disclaimer a bit, and feel no obligation to survive throws in perfect > condition. Pass them along and let developers deal with the consequences. > Exceptions should be for weird problems, and if things get weirder, so > what? Based on our experience in x86 it probably will be just fine. > > Thanks, > Dennis Kolva > Programming Director > TurtleSoft.com > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] More on Exceptions
Thiago, I'll describe what happens when our typical exception is thrown, since conditions are very different from what you describe. Before any method uses a pointer, it first does a sanity check. If nullptr it shows a dialog with file/line number and what failed, then throws an exception to avoid crashing. There are 7000+ checks, plus another 1000+ assertions for other bad states. 99% will never be called. Some throws are caught internally but most go out to the event loop, which has a try/catch block. The app has a couple megabytes of just file/line number text, since it needs to be compiled in. The original plan was to remove them in release build, but they help for user bug reports so they're permanent. Users tell us exactly where to find the problem. A few exceptions are fatal and just terminate. The database is never in unstable state so we can leave safely at any time. Actually it's unstable briefly during commits but nothing throws in there so the only danger is power failures. There probably are apps that need cleanup on terminate, but ours isn't one. In practice, 99% of throws are from something trivial/stupid- a missing field, or a link to something that doesn't need to be linked. They are caught in the event loop and users can safely continue working. In rare cases they may see a ton of weird messages and need to force-quit. As the stack unwinds after a throw, in theory it should tidy everything via scope endings and destructors. In practice, maybe there are leaks or other bugs along the way. But in theory, those bugs would show up anyhow when the stack unwinds from normal use. In practice, the setup has worked well for 20+ years. Users see helpful error messages rather than crashes. Maybe the exception throws cause subtle, unknown problems but no worse than the usual problems in any app. I think Qt should enable exceptions in QWidget etc by default, strengthen the disclaimer a bit, and feel no obligation to survive throws in perfect condition. Pass them along and let developers deal with the consequences. Exceptions should be for weird problems, and if things get weirder, so what? Based on our experience in x86 it probably will be just fine. Thanks, Dennis Kolva Programming Director TurtleSoft.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Update widget geometry BEFORE window shown
On 2024-05-24 21:14, David M. Cotter wrote:
I’ve tried everything I can think of. The ONLY one that works the way
I NEED is the first one, but that one flashes the window on the screen
#if 1
qWidgetP->show();
qWidgetP->hide();
QtLetTimersFire(0);
#endif
Hi, have you tried the old Windows trick of moving the widget to
Cleveland, i.e. way off into negative territory like Minimize does?
https://devblogs.microsoft.com/oldnewthing/20041028-00/?p=37453
Say you have this code:
auto qWidgetP = new QWidget();
qWidgetP->setGeometry({100,100,1000,1000});
qWidgetP->show();
QTimer::singleShot(1000,[qWidgetP]{ qWidgetP->hide(); });
FLashes for sure. But if you position it like this:
qWidgetP->setGeometry({-32000,-32000,1000,1000});
do all the setup and then later move it back into the normal coords.
The flash will still occur but noone will here you scream/flash.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
