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