Author ncoghlan
Recipients benjamin.peterson, ncoghlan, nikratio
Date 2013-11-08.14:34:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1383921252.22.0.541909826297.issue18861@psf.upfronthosting.co.za>
In-reply-to
Content
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)
History
Date User Action Args
2013-11-08 14:34:12ncoghlansetrecipients: + ncoghlan, benjamin.peterson, nikratio
2013-11-08 14:34:12ncoghlansetmessageid: <1383921252.22.0.541909826297.issue18861@psf.upfronthosting.co.za>
2013-11-08 14:34:12ncoghlanlinkissue18861 messages
2013-11-08 14:34:11ncoghlancreate