On Friday 6 September 2024 10:55:47 CEST Ville Voutilainen wrote: > > I'm arguing that (c) makes it *worse* because now the exception propagates > > out, causing all sorts of code to be run that we've never, ever tested > > before. > I would be rather surprised if you had tested that code before, > because it's my application > code where that exception propagates, not Qt framework code.
I meant the Qt code that the exception propagates through before reaching yours. I'm thinking of things like an accidental violation of a QList in one of the lists in QObjectPrivate::extraData, like runningTimers. Suppose the main() function puts the precondition checker in throw mode and that we do have a bug somewhere that triggers this violation deep inside servicing timers. The exception will get thrown instead of the application aborting, but then it'll propagate through Qt code that has never been tested for exceptions. I argue that your best bet here is that it attempts to propagate through Win32 DLLs or some Cocoa or Glib native APIs, which cause it to crash. Because the alternative is that it reaches an exception handler somewhere and the user code may attempt to do something while the QObject and event dispatcher state is corrupt: > > It may also be caught somewhere and execution incorrectly resumed, causing > > incorrect-state execution to continue. > > There's nothing incorrect about that; the exception will be caught and > handled, and application execution > will resume. See above. In the scenario I outlined, you cannot trust anything that uses QObject any more. And worse than crashing it is continuing to run with corrupted state. It may freeze or have weird, user-visible behaviours. Or it may corrupt user data, which then may be saved to disk, making it permanent and the data error not getting caught. > > My argument is "first, do no harm" (or "don't make it worse"). Exceptions > > should only be used if there's a proper correction code for it. > > I have that "correction code". Sure, but "bugs happen". I am arguing that putting the contract checker into exception mode expands the blast radius of when those bugs do occur. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
