Nick Coghlan added the comment:
Ah, confusion between exception has been raised and we're in an active
exception handler is almost certainly what is happening. In both issue 22906
and my previous codec exception wrapping work, we're still in the C code that
raised the exception, *before* we
Antoine Pitrou added the comment:
The interesting discovery I made while reviewing the patch for issue
22906 is that there apparently *is* implicit chaining support in
PyErr_SetObject
Indeed, there is, and it should work properly (AFAIR there was quite a bit of
debugging to make this
Nick Coghlan added the comment:
The interesting discovery I made while reviewing the patch for issue 22906 is
that there apparently *is* implicit chaining support in PyErr_SetObject:
https://hg.python.org/cpython/file/default/Python/errors.c#l70
Chris indicates that it doesn't seem to be
Nick Coghlan added the comment:
The documentation of PyErr_SetObject, PyErr_SetString et al should also be
updated to mention exception chaining.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23188
Nick Coghlan added the comment:
After looking into this further, PyErr_SetObject (and other APIs like
PyErr_SetString which call that internally) aim to handle the chaining
automatically, but they don't handle exceptions which haven't been normalized
yet.
PyErr_SetObject should probably
Nick Coghlan added the comment:
Thinking about it a bit further, I suspect implicit normalisation of chained
exceptions could cause problems when we only want to set __cause__ without
setting __context__ (e.g. codec exception chaining).
I'm going to ponder this one for a while, but happy to
Serhiy Storchaka added the comment:
_PyErr_ChainExceptions() was added because exceptions raised in C code are not
implicitly chained. The code for explicit chaining is error prone, so it was
extracted in separate function. Even with _PyErr_ChainExceptions() chaining
exceptions look complex.
