Message317307
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"); |
|
Date |
User |
Action |
Args |
2018-05-22 16:24:32 | eric.snow | set | recipients:
+ eric.snow, ncoghlan, pitrou, vstinner, serhiy.storchaka |
2018-05-22 16:24:32 | eric.snow | set | messageid: <1527006272.04.0.682650639539.issue23188@psf.upfronthosting.co.za> |
2018-05-22 16:24:31 | eric.snow | link | issue23188 messages |
2018-05-22 16:24:31 | eric.snow | create | |
|