[PyQt] Exceptions in Python Implementations of Virtuals

[Marcus Ottosson]

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>
> wrote:
>
>> 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++.
>>
>> Best,
>> Marcus
>> ​
>>
>> 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
>>> here.
>>>  On Sep 30, 2014 12:24 PM, "Phil Thompson" <phil at riverbankcomputing.com>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>> Comments?
>>>>
>>>> Phil
>>>> _______________________________________________
>>>> PyQt mailing list    PyQt at riverbankcomputing.com
>>>> http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>>>
>>>
>>> _______________________________________________
>>> PyQt mailing list    PyQt at riverbankcomputing.com
>>> http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>>>
>>
>>
>>
>> --
>> *Marcus Ottosson*
>> konstruktion at gmail.com
>>
>
>


-- 
*Marcus Ottosson*
konstruktion at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20140930/4a42d85d/attachment.html>