[PyQt] Exceptions in Python Implementations of Virtuals
konstruktion at gmail.com
Tue Sep 30 19:07:47 BST 2014
But the errors I’m talking about are even more benign.
I’m not sure I would trust a framework to distinguish between which errors
are benign and which will take my money.
On 30 September 2014 18:55, Chris Colbert <sccolbert at gmail.com> wrote:
> On Tue, Sep 30, 2014 at 1:03 PM, Marcus Ottosson <konstruktion at gmail.com>
>> Imagine a case where a finance app developer misspells some attribute
>> like palette and has insufficient test coverage. Crashing the app in the
>> middle of trade execution is a much worse outcome than failing to color the
>> line edit correctly.
>> On the other hand, misspelling in this scenario could lead to the wrong
>> results not getting noticed until it’s much too late, in which case failing
>> fast costs less.
> This really depends on the situation. If the market is volatile, you're
> talking enormous sums of money potentially lost every minute. It's better
> to catch the error during trade reconciliation and correct it then.
> But the errors I'm talking about are even more benign. The kind of thing
> where someone thinks "oh, this is just a cosmetic change" or "let me just
> fix the spelling of this label" and then think "it's so small I don't need
> to test the change". Rarely does it effect the core business logic, but
> under the proposed changes, it would keep the app from running at all.
>> I don’t think there is any right or wrong answer here, I’d vouch for
>> sticking with what is the most Pythonic and leave C++ to C++.
>> On 30 September 2014 17:52, Chris Colbert <sccolbert at gmail.com> wrote:
>>> I'm strongly -1 on this.
>>> I think exceptions should be handled consistently throughout the
>>> library. So if you were to make this change for virtual functions, it
>>> should also be made for signal handlers. But, user code excepting on the
>>> path of a signal handler or a virtual event method is very common in my
>>> experience, and not all of these exceptions prohibit the app from
>>> continuing to function.
>>> Fataling the app, on the other hand, would lead to absolute mayhem on
>>> the production floor.
>>> Imagine a case where a finance app developer misspells some attribute
>>> like palette and has insufficient test coverage. Crashing the app in the
>>> middle of trade execution is a much worse outcome than failing to color the
>>> line edit correctly.
>>> It would be nice to have an easier way than except hooks to be able to
>>> detect and handle these cases, and I think exploring options in that space
>>> is worthy of discussion. But I think qFatal is certainly the wrong approach
>>> On Sep 30, 2014 12:24 PM, "Phil Thompson" <phil at riverbankcomputing.com>
>>>> Florian asked this question but it didn't result in any discussion, so
>>>> I'd like to have another poke at it.
>>>> Currently, if an exception is raised by a Python re-implementation of a
>>>> C++ virtual then the exception is printed and the application continues. A
>>>> default result will be constructed by PyQt and returned to C++. Instead,
>>>> should PyQt print the exception and then terminate (by calling qFatal())?
>>>> Some advantages...
>>>> - consistency in what happens when an unhandled exception is raised
>>>> (ie. the application always terminates)
>>>> - such bugs become obvious and easy to find
>>>> Some disadvantages...
>>>> - incompatible with current behaviour
>>>> - may cause problems with applications that already try to handle such
>>>> exceptions using exception hooks
>>>> If I make this change it will be for PyQt5 only. I don't plan to make
>>>> the change configurable in any way.
>>>> PyQt mailing list PyQt at riverbankcomputing.com
>>> PyQt mailing list PyQt at riverbankcomputing.com
>> *Marcus Ottosson*
>> konstruktion at gmail.com
konstruktion at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the PyQt