[Python-Dev] bpo-36829: Add sys.unraisablehook()

[Steve Dower]

On 16May2019 0856, Steve Dower wrote:
> On 16May2019 0647, Victor Stinner wrote:
>> Le jeu. 16 mai 2019 à 12:57, Serhiy Storchaka <storchaka at gmail.com> a 
>> écrit :
>>>> For unraisable hook, it's not hard to imagine other useful parameters
>>>> that can be passed to the hook to provide more context about the
>>>> exception. For example, right now we only pass one object. But there
>>>> are cases where a second object would totally makes sense.
>>>
>>> If you have plans for adding new details in future, I propose to add a
>>> 6th parameter "context" or "extra" (always None currently). It is as
>>> extensible as packing all arguments into a single structure, but you do
>>> not need to introduce the structure type and create its instance until
>>> you need to pass additional info.
>>
>> In my implementation, UnraisableHookArgs is a C "structseq" type. In
>> short, it's a tuple. make_unraisable_hook_args() basically builds a
>> tuple of 4 items and uses PyTuple_SET_ITEM() to set the items.
>> _PyErr_WriteUnraisableDefaultHook() uses PyStructSequence_GET_ITEM()
>> to get items.
>>
>> The code pack and unpack UnraisableHookArgs is simple and reliable.
>>
>> An "unraisable exception" doesn't mean that Python is collapsing. It
>> only means that the code is unable to report the exception to the
>> caller: there is no reason why allocating a 4-tuple or calling a
>> simple Python function (sys.unraisablehook) would fail.
>>
>> -- 
>>
>> I dislike the compromise of having an API in 2 parts: positional
>> parameters for some parameters, and a structure for some other
>> parameters. I prefer to pack all arguments into a single structure.
> 
> I really like this API, and I agree with Victor that we don't really 
> need more than the exception info. For future expansion, we can pass in 
> a different exception, no?
> 
> I'm not even convinced we need the obj argument, or that it's a good 
> idea - this is yet another place where it's likely to be dead/dying 
> already. And what can you do with it? Resurrection seems like a really 
> bad idea, as does diving into a custom __repr__. There's no useful 
> recovery mechanism here that I'm aware of, so I'd be in favor of just 
> passing through the exception and nothing else.

Actually, if the default implementation prints the exception message, 
how is this different from sys.excepthook? Specifically, from the point 
of customizing the hooks.

If I were going to replace unraisablehook to do something on specific 
exceptions, I'm almost certainly going to replace excepthook as well, 
no? The only difference is whether there are any try/except blocks in 
between, and by definition I think the answer is no (in both cases, or 
we wouldn't have reached the hook).

Do you have scenarios in mind where you would need these to do different 
things? And would those be just as well served by a flag on the 
exception object rather than an entirely separate hook?

Cheers,
Steve