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 ncoghlan
Recipients barry, ezio.melotti, flox, lemburg, ncoghlan, vstinner
Date 2013-11-10.14:34:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CADiSq7fFf7upCBL40cHf77S=ODmXsMbkyjaio-OEcPViZ3MPUA@mail.gmail.com>
In-reply-to <527F884F.7090607@egenix.com>
Content
On 10 November 2013 23:21, Marc-Andre Lemburg <report@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.
History
Date User Action Args
2013-11-10 14:34:32ncoghlansetrecipients: + ncoghlan, lemburg, barry, vstinner, ezio.melotti, flox
2013-11-10 14:34:32ncoghlanlinkissue17828 messages
2013-11-10 14:34:31ncoghlancreate