[Interest] More on Exceptions

[Jean-Michaël Celerier]

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, <support at turtlesoft.com>
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 at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20240525/4f774549/attachment.htm>