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
Exception
s 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
andexcept
statements. The
technique contrasts with the LBYL
style common to many other languages
such as C.