Using 'try' vs. 'if' in Python

Python

Python Problem Overview


Is there a rationale to decide which one of try or if constructs to use, when testing variable to have a value?

For example, there is a function that returns either a list or doesn't return a value. I want to check result before processing it. Which of the following would be more preferable and why?

result = function();
if (result):
    for r in result:
        #process items

or

result = function();
try:
    for r in result:
        # Process items
except TypeError:
    pass;

Checking for member existence in Python

Python Solutions


Solution 1 - Python

You often hear that Python encourages EAFP style ("it's easier to ask for forgiveness than permission") over LBYL style ("look before you leap"). To me, it's a matter of efficiency and readability.

In your example (say that instead of returning a list or an empty string, the function were to return a list or None), if you expect that 99 % of the time result will actually contain something iterable, I'd use the try/except approach. It will be faster if exceptions really are exceptional. If result is None more than 50 % of the time, then using if is probably better.

To support this with a few measurements:

>>> import timeit
>>> timeit.timeit(setup="a=1;b=1", stmt="a/b") # no error checking
0.06379691968322732
>>> timeit.timeit(setup="a=1;b=1", stmt="try:\n a/b\nexcept ZeroDivisionError:\n pass")
0.0829463709378615
>>> timeit.timeit(setup="a=1;b=0", stmt="try:\n a/b\nexcept ZeroDivisionError:\n pass")
0.5070195056614466
>>> timeit.timeit(setup="a=1;b=1", stmt="if b!=0:\n a/b")
0.11940114974277094
>>> timeit.timeit(setup="a=1;b=0", stmt="if b!=0:\n a/b")
0.051202772912802175

So, whereas an if statement always costs you, it's nearly free to set up a try/except block. But when an Exception actually occurs, the cost is much higher.

Moral:

  • It's perfectly OK (and "pythonic") to use try/except for flow control,
  • but it makes sense most when Exceptions are actually exceptional.

From the Python docs:

> EAFP > > Easier to ask for forgiveness than > permission. This common Python coding > style assumes the existence of valid > keys or attributes and catches > exceptions if the assumption proves > false. This clean and fast style is > characterized by the presence of many > try and except statements. The > technique contrasts with the LBYL > style common to many other languages > such as C.

Solution 2 - Python

Your function should not return mixed types (i.e. list or empty string). It should return a list of values or just an empty list. Then you wouldn't need to test for anything, i.e. your code collapses to:

for r in function():
    # process items

Solution 3 - Python

Please ignore my solution if the code I provide is not obvious at first glance and you have to read the explanation after the code sample.

Can I assume that the "no value returned" means the return value is None? If yes, or if the "no value" is False boolean-wise, you can do the following, since your code essentially treats "no value" as "do not iterate":

for r in function() or ():
    # process items

If function() returns something that's not True, you iterate over the empty tuple, i.e. you don't run any iterations. This is essentially LBYL.

Solution 4 - Python

Generally, the impression I've gotten is that exceptions should be reserved for exceptional circumstances. If the result is expected never to be empty (but might be, if, for instance, a disk crashed, etc), the second approach makes sense. If, on the other hand, an empty result is perfectly reasonable under normal conditions, testing for it with an if statement makes more sense.

I had in mind the (more common) scenario:

# keep access counts for different files
file_counts={}
...
# got a filename somehow
if filename not in file_counts:
    file_counts[filename]=0
file_counts[filename]+=1

instead of the equivalent:

...
try:
    file_counts[filename]+=1
except KeyError:
    file_counts[filename]=1

Solution 5 - Python

> Which of the following would be more preferable and why?

Look Before You Leap is preferable in this case. With the exception approach, a TypeError could occur anywhere in your loop body and it'd get caught and thrown away, which is not what you want and will make debugging tricky.

(I agree with Brandon Corfman though: returning None for ‘no items’ instead of an empty list is broken. It's an unpleasant habit of Java coders that should not be seen in Python. Or Java.)

Solution 6 - Python

Your second example is broken - the code will never throw a TypeError exception since you can iterate through both strings and lists. Iterating through an empty string or list is also valid - it will execute the body of the loop zero times.

Solution 7 - Python

bobince wisely points out that wrapping the second case can also catch TypeErrors in the loop, which is not what you want. If you do really want to use a try though, you can test if it's iterable before the loop

result = function();
try:
    it = iter(result)
except TypeError:
    pass
else:
    for r in it:
        #process items

As you can see, it's rather ugly. I don't suggest it, but it should be mentioned for completeness.

Solution 8 - Python

As far as the performance is concerned, using try block for code that normally doesn’t raise exceptions is faster than using if statement everytime. So, the decision depends on the probability of excetional cases.

Solution 9 - Python

As a general rule of thumb, you should never use try/catch or any exception handling stuff to control flow. Even though behind the scenes iteration is controlled via the raising of StopIteration exceptions, you still should prefer your first code snippet to the second.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionartdanilView Question on Stackoverflow
Solution 1 - PythonTim PietzckerView Answer on Stackoverflow
Solution 2 - PythonBrandonView Answer on Stackoverflow
Solution 3 - PythontzotView Answer on Stackoverflow
Solution 4 - PythonManaguView Answer on Stackoverflow
Solution 5 - PythonbobinceView Answer on Stackoverflow
Solution 6 - PythonDave KirbyView Answer on Stackoverflow
Solution 7 - PythonAFogliaView Answer on Stackoverflow
Solution 8 - PythongraygerView Answer on Stackoverflow
Solution 9 - PythoniloweView Answer on Stackoverflow