Hello.
I am a bit confused with 'raise' without any arguments.
Suppose the testcase below (i hope it's correct!):
##################################
import sys
class A:
pass
class B:
pass
def foo():
try:
raise B
except:
pass
def b1 ():
try:
raise A
except:
foo ()
raise # raises A
def b2 ():
try:
raise A
except:
try:
raise B
except:
pass
raise # raises B
def b3 ():
foo ()
raise # raises B
def b4 ():
try:
raise A
except:
pass
foo ()
raise # raises A
#
try:
b1 ()
except:
print sys.exc_info()
try:
b2 ()
except:
print sys.exc_info()
try:
b3 ()
except:
print sys.exc_info()
try:
b4 ()
except:
print sys.exc_info()
################################
The semantics of raise without arguments are that the exceptions
of the current scope have a higer priority. That can be seen
in functions b1() and b2(), where although an exception of type
'B' was the last handled by python, b1() raises 'A'.
Although, b3() shows that the exceptions from other scopes *are*
available.
The b4() case demonstrates the confusion better.
IMHO, a more clean operation of raise would be either:
1) raise w/o args allowed *only* inside an except clause to
re-raise the exception being handled by the clause.
2) always re-raise the last exception no matter the scope.
It appears to me that this behaviour is a bit weird and I would
like to ask: Are the semantics of 'raise w/o args' a result of
python's implementation? If python was re-designed, would that
be different? In python 3000, would you consider changing this
and if yes, to what semantics? May this be changed in 2.5?
Thanks
jfj
-----------------
# don't hold back
--
http://mail.python.org/mailman/listinfo/python-list
