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

Steve Dower steve.dower at python.org
Thu May 16 12:02:29 EDT 2019

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. makeunraisablehookargs() basically builds a tuple of 4 items and uses PyTupleSETITEM() to set the items. PyErrWriteUnraisableDefaultHook() uses PyStructSequenceGETITEM() 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

More information about the Python-Dev mailing list