This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: try: except: ordering error
Type: behavior Stage: resolved
Components: None Versions: Python 3.3
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: DivinityArcane, georg.brandl, r.david.murray
Priority: normal Keywords:

Created on 2013-01-11 02:06 by DivinityArcane, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
2013-01-10 17_55_13-Python Shell.png DivinityArcane, 2013-01-11 02:06 Screenshot of output
Messages (3)
msg179613 - (view) Author: Justin Eittreim (DivinityArcane) Date: 2013-01-11 02:06
When running multiple nested loops (to emulate the circumstances of a program running multiple different modules at once,) each with their own try: except: block (in this case for KeyboardInterrupt,) the order of operations seems to fall out of place. As you can see in the screenshot, even though the inner-most loop should never have been left (or ended for that matter,) the parent loop catches the exception in its place on occasion. While this isn't necessarily a huge issue, for certain things it can be rather annoying and downright confusing. For most all other languages, for example, the inner-most loop would, of course, catch the exception first.

Requesting more insight on this issue.
msg179616 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-01-11 02:51
Print b happens when the interpreter is processing the loop condition for loop c.  print c happens when it is processing the body of the loop (ie: is inside the try/except in the body of the loop).  Presumably if you set your keyboard autorepeat interval short enough you could manage to get it to print a, too, while it was processing the loop condition for loop b after a keyboard interrupt that prints b.
msg179715 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2013-01-11 18:12
If I understand your issue correctly, you are expecting all three exception handlers to be called in innermost-to-outermost order. However, exceptions are not reraised automatically after "except" blocks; you can insert a bare "raise" statement in the handler to get that effect.
History
Date User Action Args
2022-04-11 14:57:40adminsetgithub: 61128
2013-01-11 18:12:44georg.brandlsetnosy: + georg.brandl
messages: + msg179715
2013-01-11 02:51:46r.david.murraysetstatus: open -> closed

nosy: + r.david.murray
messages: + msg179616

resolution: not a bug
stage: resolved
2013-01-11 02:06:26DivinityArcanecreate