Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Raise X or Raise X()?

Reply
Thread Tools

Raise X or Raise X()?

 
 
bvdp
Guest
Posts: n/a
 
      03-11-2012
Which is preferred in a raise: X or X()? I've seen both. In my specific case I'm dumping out of a deep loop:

try:
for ...
for ...
for ...
if match:
raise StopInteration()
else ...

except StopInteration:
print "found it"
 
Reply With Quote
 
 
 
 
Irmen de Jong
Guest
Posts: n/a
 
      03-11-2012
On 11-3-2012 20:04, bvdp wrote:
> Which is preferred in a raise: X or X()? I've seen both. In my specific case I'm dumping out of a deep loop:
>
> try:
> for ...
> for ...
> for ...
> if match:
> raise StopInteration()
> else ...
>
> except StopInteration:
> print "found it"


"raise X" is a special case of the 3-args raise. Effectively it just raises an instance
of X which is constructed with an empty argument list. Therefore, "raise X()" is
equivalent, as far as I know.

See http://docs.python.org/reference/sim...aise-statement

Irmen

 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      03-11-2012
On Sun, 11 Mar 2012 12:04:55 -0700, bvdp wrote:

> Which is preferred in a raise: X or X()?


Both.

Always use raise "X(*args)" when you need to provide arguments (which you
should always do for exceptions meant for the caller to see). The form
"raise X, args" should be considered discouraged, and in fact is gone in
Python 3.x.

Purely internal exceptions (which you raise and catch yourself) don't
need arguments, so there is no difference between the two forms:
"raise X" is exactly equivalent to "raise X()" with no arguments. Use
whichever takes your fancy.

Personally, I used "raise X" to mean "this doesn't need arguments and
should never have any" and "raise X()" to mean "this needs arguments but
I'm too lazy to provide them right now". Think of it as a FIXME.


--
Steven
 
Reply With Quote
 
bvdp
Guest
Posts: n/a
 
      03-12-2012

Thanks all for the comments.

> Personally, I used "raise X" to mean "this doesn't need arguments and
> should never have any" and "raise X()" to mean "this needs arguments but
> I'm too lazy to provide them right now". Think of it as a FIXME.


Yes, that makes as much sense as anything else

 
Reply With Quote
 
MRAB
Guest
Posts: n/a
 
      03-12-2012
On 11/03/2012 23:59, Steven D'Aprano wrote:
> On Sun, 11 Mar 2012 12:04:55 -0700, bvdp wrote:
>
>> Which is preferred in a raise: X or X()?

>
> Both.
>
> Always use raise "X(*args)" when you need to provide arguments (which you
> should always do for exceptions meant for the caller to see). The form
> "raise X, args" should be considered discouraged, and in fact is gone in
> Python 3.x.
>
> Purely internal exceptions (which you raise and catch yourself) don't
> need arguments, so there is no difference between the two forms:
> "raise X" is exactly equivalent to "raise X()" with no arguments. Use
> whichever takes your fancy.
>
> Personally, I used "raise X" to mean "this doesn't need arguments and
> should never have any" and "raise X()" to mean "this needs arguments but
> I'm too lazy to provide them right now". Think of it as a FIXME.
>

As some do need arguments, I'd do the opposite; no parentheses would
mean "I haven't finished yet".
 
Reply With Quote
 
Jean-Michel Pichavant
Guest
Posts: n/a
 
      03-12-2012
bvdp wrote:
> Which is preferred in a raise: X or X()? I've seen both. In my specific case I'm dumping out of a deep loop:
>
> try:
> for ...
> for ...
> for ...
> if match:
> raise StopInteration()
> else ...
>
> except StopInteration:
> print "found it"
>


I prefer the raise X() version, it fulfils the zen of python :

"Special cases aren't special enough to break the rules.
There should be one-- and preferably only one --obvious way to do it."

I still wonder why they've added the class raise form, on which purpose.

JM

 
Reply With Quote
 
Robert Kern
Guest
Posts: n/a
 
      03-12-2012
On 3/12/12 10:37 AM, Jean-Michel Pichavant wrote:
> bvdp wrote:
>> Which is preferred in a raise: X or X()? I've seen both. In my specific case
>> I'm dumping out of a deep loop:
>>
>> try:
>> for ...
>> for ...
>> for ...
>> if match:
>> raise StopInteration()
>> else ...
>>
>> except StopInteration:
>> print "found it"

>
> I prefer the raise X() version, it fulfils the zen of python :
>
> "Special cases aren't special enough to break the rules.
> There should be one-- and preferably only one --obvious way to do it."
>
> I still wonder why they've added the class raise form, on which purpose.


The class raise form used to be the only way to raise exceptions. To pass an
argument, there was special syntax:

raise Exception, "some message"

This syntax has been done away with in Python 3 in favor of regular calling
conventions. Python 3 still allows bare classes, though. I also prefer to always
raise instances of exceptions rather than bare exception classes. It simplifies
the mental model.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 
Reply With Quote
 
James Elford
Guest
Posts: n/a
 
      03-12-2012
On 11/03/12 19:04, bvdp wrote:
> Which is preferred in a raise: X or X()? I've seen both. In my specific case I'm dumping out of a deep loop:
>
> try:
> for ...
> for ...
> for ...
> if match:
> raise StopInteration()
> else ...
>
> except StopInteration:
> print "found it"


I wonder whether you need to use an exception here rather than a yield
statement? Exceptions should reflect Exceptional circumstances (and come
with associated stack trace, and so on...). The following should do
something like what you want, without raising exceptions.

>>> # Deeply loop into a collection of collections
>>> def find(collection):

.... for sub_col in collection:
.... for item in sub_col:
.... for foo in item.list_field:
.... if foo.is_match:
.... yield foo

>>> # Some junk classes to iterate over
>>> class Item(object):

.... def __init__(self, some_range):
.... self.list_field =[ListedItem(i) for i in some_range]

>>> class ListedItem(object):

.... def __init__(self, number):
.... self.tag = number
.... self.is_match = False

>>> def __str__(self):

.... return str(self.tag)

>>> # Construct a list of items
>>> l = [[Item(range(i)) for i in range(10)],

.... [Item(range(i, 2*i)) for i in range(10,20)]]

>>> l[0][9].list_field[3].is_match = True


>>> for i in find(l):

.... print(i)
3

James
 
Reply With Quote
 
Stefan Behnel
Guest
Posts: n/a
 
      03-12-2012
Irmen de Jong, 11.03.2012 21:37:
> On 11-3-2012 20:04, bvdp wrote:
>> Which is preferred in a raise: X or X()? I've seen both. In my specific case I'm dumping out of a deep loop:
>>
>> try:
>> for ...
>> for ...
>> for ...
>> if match:
>> raise StopInteration()
>> else ...
>>
>> except StopInteration:
>> print "found it"

>
> "raise X" is a special case of the 3-args raise. Effectively it just raises an instance
> of X which is constructed with an empty argument list. Therefore, "raise X()" is
> equivalent, as far as I know.


Not completely, although that may be considered an implementation detail.

When you raise an exception instance, it gets instantiated before being
raised (by your own code). So you control exactly how the exception
instance comes to life.

When you raise the class instead of the instance, it may or may not get
instantiated, depending on how it is being caught or discarded (and by
whom, e.g. internally in the interpreter). In most cases, it will be
instantiated, but only when someone catches it, i.e. at a later time, after
raising it. If the instantiation of the exception has side effects, or if
it fails for some reason (e.g. bad or missing arguments), the time of
instantiation may make a difference. It's obviously bad design to use side
effects here, but it's equally bad design to silently rely on it being side
effect free.

Note that if the exception happens to never get instantiated, you will safe
a tiny bit of time for the overall propagation. But since it's hard to tell
if that will happen or not, it would be a rather misguided micro
optimisation for most Python code to base your decision on this, at least
without prior benchmarking (with a real work-load etc.).

In general, I tend to raise exception types only for very safe and common
built-in exceptions, such as StopIteration, but whenever they take an
argument, I raise the instance instead. For user provided exceptions, there
is no real excuse for raising the type.

BTW, StopIteration takes an optional argument in Python 3.3, but that's not
a feature that is generally going to be used by Python code, I assume. So
I'll just keep raising the type.

Stefan

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      03-12-2012
On Mon, 12 Mar 2012 14:52:49 +0100, Stefan Behnel wrote:

>> "raise X" is a special case of the 3-args raise. Effectively it just
>> raises an instance of X which is constructed with an empty argument
>> list. Therefore, "raise X()" is equivalent, as far as I know.

>
> Not completely, although that may be considered an implementation
> detail.
>
> When you raise an exception instance, it gets instantiated before being
> raised (by your own code). So you control exactly how the exception
> instance comes to life.


Normally the exception is instantiated just before you raise it. Of
course, that's not compulsory. You can pre-load it if you want:

instance = ValueError("spam")
time.sleep(60)
raise instance

but generally we say

raise ValueError("spam")

and be done with it.


> When you raise the class instead of the instance, it may or may not get
> instantiated, depending on how it is being caught or discarded (and by
> whom, e.g. internally in the interpreter). In most cases, it will be
> instantiated, but only when someone catches it, i.e. at a later time,
> after raising it.


I don't think that is correct. Either the exception gets raised, or it
doesn't. If it doesn't get raised, then no instance is instantiated
(unless you did it yourself, as in the example above). But if it does get
raised, then regardless of which form you use (the class or the
instance), the exception instance *will* be instantiated. If you don't do
it yourself, the raise statement will do it.

Using Python 3.2:

>>> class TestException(Exception):

.... def __init__(self, *args):
.... print("initialising exception")
.... super().__init__(*args)
....
>>> try:

.... raise TestException
.... except:
.... pass
....
initialising exception

Whether you catch the exception or not, it still gets instantiated. Try
it and see, and if you can find some way to actually raise the exception
without instantiating the instance, I would love to see it.

Implementation-wise, at least for Python 3.2, what seems to happen as
best as I can tell from reading ceval.c, is that the opcode for raise
checks the argument. If it is already an instance, it uses that; if it is
not, it instantiates it immediately.

(see function do_raise in ceval.c)

So, technically, there may be a minuscule timing difference depending on
whether you instantiate the exception in Python code or in C code, but I
don't believe that this meaningful.


> If the instantiation of the exception has side
> effects, or if it fails for some reason (e.g. bad or missing arguments),
> the time of instantiation may make a difference.


I expect this is only relevant if you pre-instantiate the exception ahead
of time.

I suppose it is conceivable that, in a particularly odd corner case or
two (perhaps using exceptions with side effects and/or threads or
something) the nanosecond difference between raise X() and raise X might
make a difference. But I'm having difficulty seeing that this is
plausible. I think you will have to show me an example to prove it.

Certainly, without threads, I don't think there is any difference.


> It's obviously bad
> design to use side effects here, but it's equally bad design to silently
> rely on it being side effect free.


I don't understand what you are trying to say here. We rely on code being
side-effect free *all the time*. Or at least known side-effects, such as
import or list.append.


> Note that if the exception happens to never get instantiated, you will
> safe a tiny bit of time for the overall propagation.


I don't believe that is true. Looking at the C code, the exception
appears to always be instantiated once you call raise.


> But since it's hard
> to tell if that will happen or not, it would be a rather misguided micro
> optimisation for most Python code to base your decision on this, at
> least without prior benchmarking (with a real work-load etc.).
>
> In general, I tend to raise exception types only for very safe and
> common built-in exceptions, such as StopIteration, but whenever they
> take an argument, I raise the instance instead. For user provided
> exceptions, there is no real excuse for raising the type.


My excuses are:

* sometimes I don't need an error message, so why give one?
* and it makes no difference whether I instantiate the exception or let
raise do it for me



> BTW, StopIteration takes an optional argument in Python 3.3,


The time machine strikes again. StopIteration takes an optional argument
going back to at least 2.6.

steve@runes:~$ python2.6
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> raise StopIteration("out of fuel")

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration: out of fuel




--
Steven
 
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 (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
Any raise or better job after get MCSD for .NET MCSD 6 05-04-2004 05:51 PM
how to raise an error of validation ? THY ASP .Net 0 08-28-2003 04:27 AM



Advertisments