Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > [newbie] Confused with raise w/o args

Reply
Thread Tools

[newbie] Confused with raise w/o args

 
 
Fredrik Lundh
Guest
Posts: n/a
 
      02-14-2005
"jfj" <(E-Mail Removed)> wrote:

> Wait! second that. We would like to


hmm. are you seconding yourself, and refering to you and yourself as we?

> here is another confusing case:
>
> ###################
> import sys
>
> class A:
> pass
>
> class B:
> pass
>
> def foo ():
> try:
> raise B
> except:
> pass
> raise
>
> def b1():
> try:
> raise A
> except:
> foo()
>
> try:
> b1 ()
> except:
> print sys.exc_info()[0]
> ##################
>
> This reports that __main__.B is raised but wouldn't it be better
> to raise an 'A' since this is the currently handled exception?


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.

maybe you should take a deep breath, and try to figure out exactly
what's confusing to you before posting more examples.

(btw, using traceback.print_exc() instead of print sys.exc_info may
give you more clues about what's really going on.)

</F>



 
Reply With Quote
 
 
 
 
jfj
Guest
Posts: n/a
 
      02-14-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

 
Reply With Quote
 
 
 
 
jfj
Guest
Posts: n/a
 
      02-14-2005
jfj wrote:
> 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.


Wait! second that. We would like to

###############
def bar():
raise

def b5():
try:
raise A
except:
bar ()
#################

So, restricting raise into except clauses only, is not good.
Change the proposal to:
> 1) raise w/o args re-raises the exception being handled
> or UnhandledException.


here is another confusing case:

###################
import sys

class A:
pass

class B:
pass

def foo ():
try:
raise B
except:
pass
raise


def b1():
try:
raise A
except:
foo()

try:
b1 ()
except:
print sys.exc_info()[0]
##################

This reports that __main__.B is raised but wouldn't it be better
to raise an 'A' since this is the currently handled exception?

jf

 
Reply With Quote
 
jfj
Guest
Posts: n/a
 
      02-15-2005
Fredrik Lundh wrote:

> "jfj" <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Raise X or Raise X()? bvdp Python 10 03-12-2012 04:08 PM
"raise (type, value, traceback)" and "raise type, value, traceback" Jack Bates Python 0 05-02-2011 05:23 PM
raise Exception or raise Exception() ernest Python 2 11-14-2010 08:14 PM
raise or not to raise [Newbie] Jacol Python 5 02-05-2007 11:46 PM
Is there a class or method to construct url args or extract url args? Ken Varn ASP .Net 2 06-22-2005 12:26 PM



Advertisments