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

[Steve Dower]

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.

Cheers,
Steve