Nick Coghlan added the comment: It may not immediately look like it, but I think issue 17828 offers an example of a related problem. In that issue, I didn't want to *change* the exception raised, I wanted to annotate it to say "Hey, something I called raised an exception, here's some relevant local state to help you figure out what is going on" (in that case, the information to be added is the specific codec being invoked and whether it is an encoding or decoding operation).
Setting the context is somewhat similar - you don't just want to know which specific exception happened to be active when the eventually caught exception was first raised - you also want to know which already active exception handlers you passed through while unwinding the stack. So really, what may be desirable here is almost an "annotated traceback", where the interpreter can decide to hang additional information off the frame currently being unwound in the exceptions traceback, while leaving the exception itself alone. That's definitely PEP territory, but there are two distinct problems with the current exception chaining mechanism to help drive a prospective design for 3.5 (the status quo doesn't bother me enough for me to work on it myself, but if you're interested Nikolaus...) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18861> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
