[PyQt] Exceptions in Python Implementations of Virtuals

[Chris Colbert]

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.

My original stance was, and still is, that unconditionally hard aborting
the application is the wrong way to handle this.

I agree with all three points of your proposal.



On Tue, Sep 30, 2014 at 4:04 PM, Florian Bruhin <me at the-compiler.org> wrote:

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