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
