Raise X or Raise X()?

[bvdp]

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"

 

[Irmen de Jong]

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/simple_stmts.html#the-raise-statement

Irmen

 

[Steven D'Aprano]

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.

 

[bvdp]

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

 

[MRAB]

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".

 

[Jean-Michel Pichavant]

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

 

[Robert Kern]

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

 

[James Elford]

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.
.... for sub_col in collection:
.... for item in sub_col:
.... for foo in item.list_field:
.... if foo.is_match:
.... yield foo
.... def __init__(self, some_range):
.... self.list_field = [ListedItem(i) for i in some_range]
.... def __init__(self, number):
.... self.tag = number
.... self.is_match = False
.... 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

 

[Stefan Behnel]

Irmen de Jong, 11.03.2012 21:37:

"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

 

[Steven D'Aprano]

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:
.... def __init__(self, *args):
.... print("initialising exception")
.... super().__init__(*args)
........ 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.Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration: out of fuel

 

[Stefan Behnel]

Steven D'Aprano, 12.03.2012 16:08:

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:

Note that the exception handling was seriously reworked in Python 3, so
there are substantial differences to Python 2. Although maybe not so many
at the Python code level.

.... def __init__(self, *args):
.... print("initialising exception")
.... super().__init__(*args)
....
.... 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)

Right, it normalises the exception immediately, also in older Python
versions. That's different at the C layer, but it looks like the
interpreter does the right (i.e. only safe) thing for Python code. Good to
know - and thanks for clearing this up.

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.

The difference can be substantial in C code, especially for something like
StopIteration if the instantiation can be avoided (in some cases even
raising the exception is avoided completely!).

However, given that Python code apparently can't raise types without
instantiating them, I agree that it's not worth looking for a difference at
that level.

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.

Even with threads it will be hard to get at this difference due to the GIL.
I can't see anything in do_raise() that would allow foreign code to run
between the evaluation of the "raise" opcode and starting to instantiate
the exception.

I don't understand what you are trying to say here. We rely on code being
side-effect free *all the time*.

That's fine for builtin stuff, functions etc. But for user provided
exceptions, why should you make your code dependent on a side effect free
instantiation just to be able to raise them without parentheses? Sounds
like too little a gain to me.

Besides, this is getting way hypothetical.

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

My fault, I was thinking at the C level again.

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.Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration: out of fuel

Right, I think it's even at least 2.4 and likely much older than that. What
I meant to say was that StopIteration has a "value" (an actual property) in
Python 3.3, which represents its first argument. So that argument actually
has specific semantics (see PEP 380), instead of just "being there".

Stefan