[ python-Bugs-973103 ] empty raise after handled exception
SourceForge.net
noreply at sourceforge.net
Tue Oct 4 05:45:06 CEST 2005
Bugs item #973103, was opened at 2004-06-15 02:36
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973103&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Niki Spahiev (nikis)
Assigned to: Neal Norwitz (nnorwitz)
Summary: empty raise after handled exception
Initial Comment:
executing empty raise after handled exception produces
wrong traceback.
no exception:
Traceback (most recent call last):
File "bug.py", line 19, in ?
test(i)
File "bug.py", line 15, in test
badfn()
File "bug.py", line 5, in badfn
raise
TypeError: exceptions must be classes, instances, or
strings (deprecated), not NoneType
handled exception:
no
Traceback (most recent call last):
File "bug.py", line 19, in ?
test(i)
File "bug.py", line 15, in test
badfn()
File "bug.py", line 11, in test
print d[12345]
KeyError: 12345
----------------------------------------------------------------------
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 20:45
Message:
Logged In: YES
user_id=33168
Ok, Raymond fixed the problem. The wording is now:
raise re-raises the last exception that was active in the
current scope. If no exception is active in the current
scope, a TypeError exception is
raised indicating that this is an error (if running under
IDLE, a Queue.Empty exception is raised instead).
I fixed Armins problem with continue.
----------------------------------------------------------------------
Comment By: Armin Rigo (arigo)
Date: 2005-10-03 05:59
Message:
Logged In: YES
user_id=4771
Sorry, my mistake. I confused the try: part and the finally: part of the try:finally:. You can use 'continue' in the former but not in the latter.
I don't see off-hand a deep problem in supporting 'continue' in the finally: part, which probably means that I am not thinking hard enough.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 21:38
Message:
Logged In: YES
user_id=33168
Armin, your comment about continue says that it's not
illegal inside a try/finally? Is that exactly correct?
continue can be used inside a try, except, else, but not
finally from my testing. Is that correct?
I agree that the wording of 7.4 is still not correct. The
try should be changed to a finally. Should the laziness
comment be removed? Should continue be allowed inside a
finally? Does the exception get eatten like return inside a
finally?
6.9 needs some work too. I asked Raymond about some of the
current wording which he seems to have modified last.
----------------------------------------------------------------------
Comment By: Armin Rigo (arigo)
Date: 2004-06-24 03:06
Message:
Logged In: YES
user_id=4771
This is the intended behavior, although the docs that explain that are not too clear: "raise" is equivalent to re-raising what "sys.get_info()" returns; the docs about sys.get_info() explain in detail why you get this behavior.
The language reference 6.9 should mention this. (Btw the language reference 7.4 still says that continue is illegal within try:finally:, which is no longer the case.)
The reason sys.get_info() has access to the exception handled in a parent frame is to be able to implement things like traceback.print_exc(). But I don't know exactly why it should be the case that an exception remains active after its handler finished.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973103&group_id=5470
More information about the Python-bugs-list
mailing list