is there any overheard with try/except statements?

[John Salerno]

One of the things I learned with C# is that it's always better to handle
any errors that might occur within the codes itself (i.e. using if
statements, etc. to catch potential out of range indexing) rather than
use too many try/catch statements, because there is some overhead every
time the program encounters the try.

Is this the case at all with Python, in terms of extra work or slower
speed? Or is try/except implemented differently in Python than it is in
other languages, so that it runs just like any other code?

Thanks.

 

[Roy Smith]

One of the things I learned with C# is that it's always better to handle
any errors that might occur within the codes itself (i.e. using if
statements, etc. to catch potential out of range indexing) rather than
use too many try/catch statements, because there is some overhead every
time the program encounters the try.

Is this the case at all with Python, in terms of extra work or slower
speed? Or is try/except implemented differently in Python than it is in
other languages, so that it runs just like any other code?

Thanks.

Repeat after me: "Python is not <fill in name of your favorite language>"

In C++ (and, I assume, C#), exception handling is relatively expensive, and
is avoided for this reason. It's also avoided (in C++, anyway) because
it's only in the past few (5-10) years that you could pretty much count on
whatever compiler you were using implementing them correctly. Lastly, many
C++/C# programmers came from C, where exceptions don't exist, so they're
not used to using them.

But, that's not Python. In Python, exceptions work as advertised, and
they're cheap. The pythonic way to do things is to embrace the maxim that
"it's easier to ask forgivness than to ask permission". It is usually
cleaner and faster to write a try block than an if statement. For example,
I'll write:

try:
x = foo[y]
except IndexError:
blah

instead of

if y < len (foo):
x = foo[y]
else:
blah

every time.

 

[Steven D'Aprano]

One of the things I learned with C# is that it's always better to handle
any errors that might occur within the codes itself (i.e. using if
statements, etc. to catch potential out of range indexing) rather than
use too many try/catch statements, because there is some overhead every
time the program encounters the try.

Is this the case at all with Python, in terms of extra work or slower
speed? Or is try/except implemented differently in Python than it is in
other languages, so that it runs just like any other code?

Setting up the try... portion of the block is very
lightweight. There is overhead, of course, but it is
very little, and potentially less overhead that
checking for the error condition. Dropping into the
except... portion is not so lightweight.

The classic example of the "look before you leap" and
"just do it" idioms involves looking up a key in a
dictionary:

# method one
if some_dict.has_key(key):
do_something_with(some_dict[key])
else:
do_something_else()

# method two
try:
do_something_with(some_dict[key])
except KeyError:
do_something_else()


If you expect lots of missing keys, the first method
will be quicker; if only a few, the second.

 

[Paul McNett]

One of the things I learned with C# is that it's always better to handle
any errors that might occur within the codes itself (i.e. using if
statements, etc. to catch potential out of range indexing) rather than
use too many try/catch statements, because there is some overhead every
time the program encounters the try.

Is this the case at all with Python, in terms of extra work or slower
speed? Or is try/except implemented differently in Python than it is in
other languages, so that it runs just like any other code?

The try structure is very efficient. However, when an exception happens
at runtime, the creation of the exception object is expensive.

That said, it does seem to be considered Pythonic to "ask for
forgiveness" instead of "asking for permission". If you check for every
exceptional possibility before actually doing the thing you want to do,
your code gets ugly very quickly.

I would use try...catch liberally, and then if profiling determines that
you have a performance bottleneck (e.g., because an exception object is
being created in lots of iterations of a loop) then factor out the try
block in that case, placing a comment explaining why you did it that way.

 

[John Salerno]

One of the things I learned with C# is that it's always better to handle
any errors that might occur within the codes itself (i.e. using if
statements, etc. to catch potential out of range indexing) rather than
use too many try/catch statements, because there is some overhead every
time the program encounters the try.

Is this the case at all with Python, in terms of extra work or slower
speed? Or is try/except implemented differently in Python than it is in
other languages, so that it runs just like any other code?

Thanks.

Thanks guys! I had a feeling exceptions were nothing like in C languages
(i.e. a pain to deal with).

 

[Alex Martelli]

Thanks guys! I had a feeling exceptions were nothing like in C languages
(i.e. a pain to deal with).

Right. Anyway, Python makes it easy to MEASURE speed issues! For
example, say that you wonder whether it's better to check a division by
0 in advance (you expect it to happen one in N times on average) or rely
on catching ZeroDivisionError -- one rare case where the two approaches
are just about equally easy to code, so you want to use the faster one.
Well, *MEASURE*...:

helen:~ alex$ python -mtimeit 'for x in range(33):
if x==0: pass
else: z=1.0/x
'
10000 loops, best of 3: 29.5 usec per loop

helen:~ alex$ python -mtimeit 'for x in range(33):
try: z=1.0/x
except ZeroDivisionError: pass
'
10000 loops, best of 3: 46.4 usec per loop

So, if a 0 happens about ` times in 33, Look Before You Leap (LBYL) is
faster than Easier to Ask Forgiveness than Permission (EAFP) in this
specific case -- and by using code that's close to your "real" one you
also learn how important to performance is to choose one or ther other.

In general, it's more frequent for EAFP to be handier and more solid,
and performance may well not matter -- but if you find yourself trying
to squeeze every last drop of performance from a region of your code
that profiling has shown to be a bottleneck, module timeit can help!


Alex

 

[John Salerno]

Alex Martelli wrote:

In general, it's more frequent for EAFP to be handier and more solid,
and performance may well not matter -- but if you find yourself trying
to squeeze every last drop of performance from a region of your code
that profiling has shown to be a bottleneck, module timeit can help!

Thanks Alex, great information. I learn way too much new information
every day on this newsgroup.

 

[Magnus Lycka]

Thanks guys! I had a feeling exceptions were nothing like in C languages
(i.e. a pain to deal with).

Since when does C have exceptions? (You're not confusing C with C++
or C#?)

 

[Magnus Lycka]

One of the things I learned with C# is that it's always better to handle
any errors that might occur within the codes itself (i.e. using if
statements, etc. to catch potential out of range indexing) rather than
use too many try/catch statements, because there is some overhead every
time the program encounters the try.

"Premature optimization is the root of all evil (or at least most of
it) in programming."

 

[John Salerno]

Since when does C have exceptions? (You're not confusing C with C++
or C#?)

I meant C-based languages, like C#.