[PyQt] Exception within Slot causes Abort

Dave Gradwell davegradwell at yahoo.co.uk
Sun Mar 20 13:20:41 GMT 2016


> How would you handle the exception in your example (with the QTimer)
> either way? You aren't in control when Qt will call that function
> (from C++), so I don't see how you could.

Instead of being drawn into the nitty gritty I would just go back to mention how nice and pythonic the experience was in PyQt 5.4.
Regardless of where you raised your exception, the consequence was consistent and proportionate.

With PyQt 5.5 the behaviour is inconsistent (consequence depends on context); and aborting because you encountered something exceptional seems really quite disproportionate to me. And not at all in the spirit of Exceptions as a programmer's friend. 
Although judging by your links (thank you) I may have missed the boat with my opinion.

> No, it doesn't continue. It quits.
I am unable to see this behaviour.
For me, with PyQt 5.4, it continues. 
And to clarify what I mean by 'it continues' I could either say 'it doesn't abort' or 'it behaves like a non PyQt Python program would'. I am not suggesting it pushes on past the exception or something ridiculous like that.

Now I suppose I could just log exceptional things myself (instead of raising python exceptions) but the way that PyQt 5.4 worked out-of-the-box just seemed so nice.
I don't really want logging. I don't really want aborting. I want exception throwing and catching!
It's particularly hard to bear because the new behaviour of an exception causing an abort seems so orthogonal to the nice intent of exceptions which I've always thought helped programmers and brought a better experience for users.
Maybe I misunderstand Exceptions. 
If so, what construct can I use to regain the nice behaviour of PyQt 5.4?

> Using a custom sys.excepthook, e.g. to show a crash window or so.
I hear what you're saying but this feels pretty strong handed, as bad as installing a custom Qt message handler.
Also, the Abortion is in full swing by this time.  I.e. We're doomed.  No?

Dave.

> On 20 Mar 2016, at 11:44, Florian Bruhin <me at the-compiler.org> wrote:
> 
> * Dave Gradwell <davegradwell at yahoo.co.uk> [2016-03-20 10:55:26 +0000]:
>> Appreciated, but if I raise an exception within a slot then Python
>> is aborted; I can't really catch anything 'up chain' and handle it
>> appropriately because the entire Python process is being torn
>> down/aborted.
> 
> How would you handle the exception in your example (with the QTimer)
> either way? You aren't in control when Qt will call that function
> (from C++), so I don't see how you could.
> 
> If I'm understanding things right, there's only really two choices
> PyQt can take here - either it *needs to* return something to the C++
> caller (which is usually some default value for the given type, and
> that in turn can invoke undefined behaviour), or it bails out using
> abort().
> 
> That's why in earlier PyQt versions, with such exceptions, you only
> see a stacktrace printed out, but your application continues to run
> (potentially with undefined behaviour). Bailing out seems to be the
> far safer choice.
> 
> See [1] for some backstory and [2]/[3] for the discussion where this
> was implemented for some more backstory.
> 
> [1] https://www.riverbankcomputing.com/pipermail/pyqt/2014-September/034806.html
> [2] https://www.riverbankcomputing.com/pipermail/pyqt/2014-September/034873.html
> [3] https://www.riverbankcomputing.com/pipermail/pyqt/2014-October/034888.html
> 
>> But, in the more boring/normal situation, if I raise an exception
>> elsewhere (ie outside of a slot), Python is not aborted, throws the
>> exception 'up chain' and, if not otherwise caught, nicely writes the
>> error out as an error and continues.
> 
> No, it doesn't continue. It quits.
> 
>> There may be ways to defeat qFatal() issuing the Abort (installing a
>> different logger?) but that doesn't seem like the right thing to do.
> 
> Using a custom sys.excepthook, e.g. to show a crash window or so.
> 
> Florian
> 
> -- 
> http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
>   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>         I love long mails! | http://email.is-not-s.ms/
> _______________________________________________
> PyQt mailing list    PyQt at riverbankcomputing.com
> https://www.riverbankcomputing.com/mailman/listinfo/pyqt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20160320/2ee1c451/attachment.html>


More information about the PyQt mailing list