Fredrik Lundh wrote:
"jfj" <[EMAIL PROTECTED]> wrote:
Wait! second that. We would like to
hmm. are you seconding yourself, and refering to you and yourself as we?
:)
"we" refers to all python users.
no. your foo() function raises B, and is called from the exception
handler in b1. exception handlers are free to raise new exceptions
at any time.
Yes but 'B' has been handled while the handler of 'A' has not finished yet.
Here is a better example:
##################
# comment out one of the two
# raise statements to test this
import traceback
def foo():
raise # this raises an 'A'
try:
raise B
except:
pass
raise # this raises a 'B'. I find this peculiar
try:
try:
raise A
except:
foo()
except:
traceback.print_exc()
##################
It seems that there are no uses of this "feature".
I guess that's the easy way to implement re-raise in CPython.
I quickly grepped through the sources (;)) and it seems that
perhaps it would be possible to introduce a new opcode
JUMP_FORWARD_CLEANUP_EXC which would be used to leave except clauses.
Then, RAISE_VARARGS would push exceptions on to an "exception stack"
and JUMP_FORWARD_CLEANUP_EXC would pop them.
The bottom element in such an exception stack would be the
UnhandledException. 're-raise' would use the stack-top exception.
However, there are no bytecode changes until AST is merged, so this
will have to wait..
jfj
--
http://mail.python.org/mailman/listinfo/python-list
