[newbie] Confused with raise w/o args

jfj jfj at freemail.gr
Mon Feb 14 16:45:56 EST 2005


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




More information about the Python-list mailing list