[PyQt] Exceptions in Python Implementations of Virtuals
Florian Bruhin
me at the-compiler.org
Tue Sep 30 21:04:16 BST 2014
* 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20140930/7c5254b3/attachment-0001.sig>
More information about the PyQt
mailing list