<div dir="ltr">I don't think anyone in this thread has advocated silently ignoring errors. In my original post I even advocated for a discussion about better ways of handling them than an exception hook. <div><br></div><div>My original stance was, and still is, that unconditionally hard aborting the application is the wrong way to handle this.</div><div><br></div><div>I agree with all three points of your proposal.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 30, 2014 at 4:04 PM, Florian Bruhin <span dir="ltr"><<a href="mailto:me@the-compiler.org" target="_blank">me@the-compiler.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Phil Thompson <<a href="mailto:phil@riverbankcomputing.com">phil@riverbankcomputing.com</a>> [2014-09-30 17:23:08 +0100]:<br>
<span class="">> Florian asked this question but it didn't result in any discussion, so I'd<br>
> like to have another poke at it.<br>
<br>
</span>Thanks for bringing this up again, Phil!<br>
<br>
An ideal solution would fail loudly (i.e. quit) on exceptions, but<br>
allow the developer to override that behaviour. Or in terms of the Zen<br>
of Python[1]: "Errors should never pass silently. - Unless explicitly<br>
silenced.". That's how all languages I know of which have exceptions<br>
work. Hell, that's the whole *point* of exceptions.<br>
<br>
As it's been said previously: If an application raises an exception,<br>
it's broken to begin with. It might make sense to catch the exception<br>
at a specific point (e.g. with a web application, display an 500 error<br>
and abort that request, but continue running), but that should *not*<br>
happen automatically and without a defined point *where* this happens.<br>
<br>
If your application continues to run fine after an ignored exception,<br>
that's out of sheer luck, it might as well do *anything*<br>
unpredictable.<br>
<br>
Regarding the financial applications, consider this: Would you rather<br>
have your transaction to be interrupted (and hopefully rolled back),<br>
or just having some undefined behaviour because, let's say, you had a<br>
ZeroDevisionError somewhere and PyQt has to return something to C++?<br>
<br>
But as said, I think it must be possible for a developer to override<br>
the "hard-quit on exceptions" behaviour - for example I have an<br>
exception hook which displays a nice error dialog[2] to the user so<br>
they can report the issue automatically and restart while recovering<br>
the state they were in (in my case, open tabs in a browser).<br>
<br>
My proposal would be this:<br>
<br>
- Make it configurable to call qFatal on exceptions which would<br>
otherwise pass silently.<br>
- Turn it off by default so it doesn't break the current behaviour.<br>
- *Force* qFatal (even when turned off) for situations where we know<br>
for sure there will be a segfault, e.g.<br>
QNetworkAccessManager::createRequest, or according to [3] also<br>
QGraphicsItem::paint.<br>
<br>
Some other random (advanced) ideas:<br>
<br>
- Would it be possible to prevent Qt to continue running while still<br>
continuing to run Python code, so a (non-GUI) sys.excepthook could<br>
be run without Qt having undefined behaviour?<br>
- Maybe do something like python's faulthandler[4] and allow a file<br>
handle to be passed, to which the exception info then gets written,<br>
so a crash report could be displayed on the next start?<br>
<br>
Florian<br>
<br>
[1] <a href="http://legacy.python.org/dev/peps/pep-0020/" target="_blank">http://legacy.python.org/dev/peps/pep-0020/</a><br>
[2] <a href="http://t.cmpl.cc/qutebrowser_crash.png" target="_blank">http://t.cmpl.cc/qutebrowser_crash.png</a><br>
[3] <a href="http://stackoverflow.com/questions/11945183/" target="_blank">http://stackoverflow.com/questions/11945183/</a><br>
[4] <a href="https://docs.python.org/3/library/faulthandler.html" target="_blank">https://docs.python.org/3/library/faulthandler.html</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<a href="http://www.the-compiler.org" target="_blank">http://www.the-compiler.org</a> | <a href="mailto:me@the-compiler.org">me@the-compiler.org</a> (Mail/XMPP)<br>
GPG 0xFD55A072 | <a href="http://the-compiler.org/pubkey.asc" target="_blank">http://the-compiler.org/pubkey.asc</a><br>
I love long mails! | <a href="http://email.is-not-s.ms/" target="_blank">http://email.is-not-s.ms/</a><br>
</font></span><br>_______________________________________________<br>
PyQt mailing list <a href="mailto:PyQt@riverbankcomputing.com">PyQt@riverbankcomputing.com</a><br>
<a href="http://www.riverbankcomputing.com/mailman/listinfo/pyqt" target="_blank">http://www.riverbankcomputing.com/mailman/listinfo/pyqt</a><br></blockquote></div><br></div>