<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">How would you handle the exception in your example (with the QTimer)<br>either way? You aren't in control when Qt will call that function<br>(from C++), so I don't see how you could.</span></font></blockquote><div><br></div><div>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.</div><div>Regardless of where you raised your exception, the consequence was consistent and proportionate.</div><div><br></div><div>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. </div><div>Although judging by your links (thank you) I may have missed the boat with my opinion.</div><div><br></div><div><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">No, it doesn't continue. It quits.</span></font></blockquote>I am unable to see this behaviour.</div><div>For me, with PyQt 5.4, it continues. </div><div>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.</div><div><br></div><div>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<span style="background-color: rgba(255, 255, 255, 0);"> just seemed so nice.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">I don't really want logging. I don't really want aborting. I want exception throwing and catching!</span></div><div>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.</div>Maybe I misunderstand Exceptions. </div><div>If so, what construct can I use to regain the nice behaviour of PyQt 5.4?</div><div><br></div><div><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">Using a custom sys.excepthook, e.g. to show a crash window or so.</span></font></blockquote>I hear what you're saying but this feels pretty strong handed, as bad as installing a custom Qt message handler.</div><div>Also, the Abortion is in full swing by this time. I.e. We're doomed. No?</div><div><br></div><div>Dave.</div><div><br>On 20 Mar 2016, at 11:44, Florian Bruhin <<a href="mailto:me@the-compiler.org">me@the-compiler.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>* Dave Gradwell <<a href="mailto:davegradwell@yahoo.co.uk">davegradwell@yahoo.co.uk</a>> [2016-03-20 10:55:26 +0000]:</span><br><blockquote type="cite"><span>Appreciated, but if I raise an exception within a slot then Python</span><br></blockquote><blockquote type="cite"><span>is aborted; I can't really catch anything 'up chain' and handle it</span><br></blockquote><blockquote type="cite"><span>appropriately because the entire Python process is being torn</span><br></blockquote><blockquote type="cite"><span>down/aborted.</span><br></blockquote><span></span><br><span>How would you handle the exception in your example (with the QTimer)</span><br><span>either way? You aren't in control when Qt will call that function</span><br><span>(from C++), so I don't see how you could.</span><br><span></span><br><span>If I'm understanding things right, there's only really two choices</span><br><span>PyQt can take here - either it *needs to* return something to the C++</span><br><span>caller (which is usually some default value for the given type, and</span><br><span>that in turn can invoke undefined behaviour), or it bails out using</span><br><span>abort().</span><br><span></span><br><span>That's why in earlier PyQt versions, with such exceptions, you only</span><br><span>see a stacktrace printed out, but your application continues to run</span><br><span>(potentially with undefined behaviour). Bailing out seems to be the</span><br><span>far safer choice.</span><br><span></span><br><span>See [1] for some backstory and [2]/[3] for the discussion where this</span><br><span>was implemented for some more backstory.</span><br><span></span><br><span>[1] <a href="https://www.riverbankcomputing.com/pipermail/pyqt/2014-September/034806.html">https://www.riverbankcomputing.com/pipermail/pyqt/2014-September/034806.html</a></span><br><span>[2] <a href="https://www.riverbankcomputing.com/pipermail/pyqt/2014-September/034873.html">https://www.riverbankcomputing.com/pipermail/pyqt/2014-September/034873.html</a></span><br><span>[3] <a href="https://www.riverbankcomputing.com/pipermail/pyqt/2014-October/034888.html">https://www.riverbankcomputing.com/pipermail/pyqt/2014-October/034888.html</a></span><br><span></span><br><blockquote type="cite"><span>But, in the more boring/normal situation, if I raise an exception</span><br></blockquote><blockquote type="cite"><span>elsewhere (ie outside of a slot), Python is not aborted, throws the</span><br></blockquote><blockquote type="cite"><span>exception 'up chain' and, if not otherwise caught, nicely writes the</span><br></blockquote><blockquote type="cite"><span>error out as an error and continues.</span><br></blockquote><span></span><br><span>No, it doesn't continue. It quits.</span><br><span></span><br><blockquote type="cite"><span>There may be ways to defeat qFatal() issuing the Abort (installing a</span><br></blockquote><blockquote type="cite"><span>different logger?) but that doesn't seem like the right thing to do. </span><br></blockquote><span></span><br><span>Using a custom sys.excepthook, e.g. to show a crash window or so.</span><br><span></span><br><span>Florian</span><br><span></span><br><span>-- </span><br><span><a href="http://www.the-compiler.org">http://www.the-compiler.org</a> | <a href="mailto:me@the-compiler.org">me@the-compiler.org</a> (Mail/XMPP)</span><br><span> GPG: 916E B0C8 FD55 A072 | <a href="http://the-compiler.org/pubkey.asc">http://the-compiler.org/pubkey.asc</a></span><br><span> I love long mails! | <a href="http://email.is-not-s.ms/">http://email.is-not-s.ms/</a></span><br></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>PyQt mailing list <a href="mailto:PyQt@riverbankcomputing.com">PyQt@riverbankcomputing.com</a></span><br><span><a href="https://www.riverbankcomputing.com/mailman/listinfo/pyqt">https://www.riverbankcomputing.com/mailman/listinfo/pyqt</a></span></div></blockquote></div></body></html>