This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Expose PyErr_ChainExceptions in the stable API
Type: enhancement Stage: patch review
Components: C API Versions: Python 3.11
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: chris.jerdonek, gregory.p.smith, pablogsal, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2021-08-17 17:44 by pablogsal, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 27799 open pablogsal, 2021-08-17 17:45
Messages (6)
msg399777 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-08-17 17:44
Currently, exception chaining in the C-API must be done by hand. This is a painstaking process that involves several steps and is very easy to do incorrectly.

We currently have a private function: _PyErr_ChainExceptions that does this job. Given that exception chaining is a very fundamental operation, this functionality must be exposed in the stable C-API
msg399820 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-08-18 04:09
As the original author of _PyErr_ChainExceptions() (issue21715) I am not sure that its name and signature are optimal. It did not matter while it was internal function because we could change them at any moment, but for public API the design should be more thoughtful.

Is passing three arguments convenient enough? Would not be better to pass them as a single argument like in _PyErr_ChainStackItem()? Is the function name good? Should we provide several similar functions for setting __context__, __cause__ and both?

There are other, more specialized, helpers: _PyErr_FormatFromCause() and _PyErr_TrySetFromCause().

There are also some flaws in setting __context__ and __cause__ (see issue39725). Perhaps we will design better concept of chaining exceptions in future.
msg399835 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-08-18 11:09
Serhiy, what do you suggest we should do then?
msg400101 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2021-08-22 19:53
I agree with Serhiy that this API isn't necessarily the right one. It's just what happens to be there now. Also, we're still not clear on our stance towards cycles (see the issue25782 discussion). (Maybe the exposed version should result in an error if it would cause a cycle to be created.) Someone would need to think through what the API should be, though.
msg400107 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-08-22 22:10
As long as the cycles don't actually end in a crash or an infinite cycle, I think is fine to not include them in the contact.

Even if that were included I don't think is actually a problem. Many APIs in C or C++ require the user to not form cycles, for instance, shared pointers in the c++ stdlib.
msg408245 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2021-12-10 19:07
related: https://www.python.org/dev/peps/pep-0490/ (rejected pep to auto-chain from C API calls)

I don't come across it often, but I did just review some code at work today where the chain might have been nice (though not a big deal).
History
Date User Action Args
2022-04-11 14:59:48adminsetgithub: 89101
2021-12-10 19:07:14gregory.p.smithsetnosy: + gregory.p.smith
messages: + msg408245
2021-08-22 22:10:47pablogsalsetmessages: + msg400107
2021-08-22 19:53:20chris.jerdoneksetnosy: + chris.jerdonek
messages: + msg400101
2021-08-18 11:09:53pablogsalsetmessages: + msg399835
2021-08-18 04:09:59serhiy.storchakasetversions: + Python 3.11
nosy: + serhiy.storchaka

messages: + msg399820

components: + C API
type: enhancement
2021-08-17 17:45:42pablogsalsetkeywords: + patch
stage: patch review
pull_requests: + pull_request26267
2021-08-17 17:44:23pablogsalcreate