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

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.

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.

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.

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.