[ python-Bugs-973103 ] empty raise after handled exception

[SourceForge.net]

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