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.

Author eric.snow
Recipients eric.snow, ncoghlan, pitrou, serhiy.storchaka, vstinner
Date 2018-05-22.16:24:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1527006272.04.0.682650639539.issue23188@psf.upfronthosting.co.za>
In-reply-to
Content
FTR, see PEP 490 ("Chain exceptions at C level") which proposed implicitly chaining exceptions in the PyErr_* API.

While that PEP was rejected (not all exceptions should be chained), it does make a good point about the clunkiness of using _PyErr_ChainExceptions():

    PyObject *exc, *val, *tb;
    PyErr_Fetch(&exc, &val, &tb);
    PyErr_Format(ZipImportError, "can't open Zip file: %R", archive);
    _PyErr_ChainExceptions(exc, val, tb);

So if we are going to add a public helper function, let's consider adding one that simplifies usage.  For instance, how about one that indicates the next exception set should chain:

    PyErr_ChainNext();
    PyErr_Format(ZipImportError, "can't open Zip file: %R", archive);

Or perhaps we should revive PEP 490 with an opt out mechanism for the cases where we don't want chaining:

    PyErr_NoChainNext();
    PyErr_Format(PyExc_RuntimeError, "uh-oh");
History
Date User Action Args
2018-05-22 16:24:32eric.snowsetrecipients: + eric.snow, ncoghlan, pitrou, vstinner, serhiy.storchaka
2018-05-22 16:24:32eric.snowsetmessageid: <1527006272.04.0.682650639539.issue23188@psf.upfronthosting.co.za>
2018-05-22 16:24:31eric.snowlinkissue23188 messages
2018-05-22 16:24:31eric.snowcreate