Nick Coghlan added the comment: On 10 November 2013 23:21, Marc-Andre Lemburg <rep...@bugs.python.org> wrote: > > Marc-Andre Lemburg added the comment: > > On 10.11.2013 14:03, Nick Coghlan wrote: >> >> Updated patch (v5) with a more robust chaining mechanism provided as a >> private "_PyErr_TrySetFromCause" API. This version eliminates the previous >> whitelist in favour of checking directly for the ability to replace the >> exception with another instance of the same type without losing information. >> >> This version also has more direct tests of the exception wrapping behaviour >> as a dedicated test class. >> >> If I don't hear any objections in the next couple of days, I plan to commit >> this version. > > This doesn't look right: > > diff -r 1ee45eb6aab9 Include/pyerrors.h > --- a/Include/pyerrors.h Sat Nov 09 23:15:52 2013 +0200 > +++ b/Include/pyerrors.h Sun Nov 10 22:54:04 2013 +1000 > ... > +PyAPI_FUNC(PyObject *) _PyErr_TrySetFromCause( > + const char *prefix_format, /* ASCII-encoded string */ > + ... > + );
The signature? That API doesn't currently let you change the exception type, only the message (since the codecs machinery doesn't need to change the exception type, and changing the exception type is fraught with peril from a backwards compatibility point of view). > BTW: Why don't we make that API a public one ? It could be useful > in C extensions as well. Because I'm not sure it's a good idea in general and hence am wary of promoting it too much at this point in time (especially given the severe limitations of what it can currently wrap). I'm convinced it's worth it in this particular case (since being told the codec involved directly makes the meaning of codec errors much clearer and even with the limitations it can still wrap most errors from standard library codecs), and the implementation *has* to be in exceptions.c since it pokes around comparing the exception details to the internals of BaseException to figure out if it can safely wrap the exception or not. Issue 18861 also makes me wonder if there's an underlying structural problem in the way exception chaining currently works that could be better solved by making it possible to annotate traceback frames while unwinding the stack, which also makes me disinclined to add to the public C API in this area before 3.5. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17828> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
