Nick Coghlan added the comment:
I actually think Nikratio is right about the way this *should* work
(intuitively).
I'm just not sure it's feasible to *implement* those semantics in CPython
without significant changes to the way exception handling works - I don't
believe the exception chaining code can currently tell the difference between
the cases:
# No context on Exception3 is exactly what we want
try:
try:
raise Exception1
except Exception1:
raise Exception2
except Exception2 as exc
raise Exception3 from Exception2
# Not seeing Exception1 as the context for Exception3 is surprising!
try:
raise Exception1
except Exception1:
try:
raise Exception2
except Exception2 as exc
raise Exception3 from Exception2
In a certain sense, exceptions need to be able to have *multiple* contexts to
handle this case properly without losing data. Frames would need to tag
exceptions appropriately with the context details as an unhandled exception
passed through a frame that was currently running an exception handler.
So even though it doesn't require new syntax, I think it *does* require a PEP
if we're going to change this (and we still haven't fully dealt with the
consequence of the last one - the display options for tracebacks are still a
bit limited)
----------
_______________________________________
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
