Clash Royale CLAN TAG#URR8PPP

Is it a good practice to use try-except-else in Python?

From time to time in Python, I see the block:

try:
try_this(whatever)
except SomeException as exception:
#Handle exception
else:
return something


What is the reason for the try-except-else to exist?

I do not like that kind of programming, as it is using exceptions to perform flow control. However, if it is included in the language, there must be a good reason for it, isn't it?

It is my understanding that exceptions are not errors, and that they should only be used for exceptional conditions (e.g. I try to write a file into disk and there is no more space, or maybe I do not have permission), and not for flow control.

Normally I handle exceptions as:

something = some_default_value
try:
something = try_this(whatever)
except SomeException as exception:
#Handle exception
finally:
return something


Or if I really do not want to return anything if an exception happens, then:

try:
something = try_this(whatever)
return something
except SomeException as exception:
#Handle exception


8 Answers
8

"I do not know if it is out of ignorance, but I do not like that
kind of programming, as it is using exceptions to perform flow control."

In the Python world, using exceptions for flow control is common and normal.

Even the Python core developers use exceptions for flow-control and that style is heavily baked into the language (i.e. the iterator protocol uses StopIteration to signal loop termination).

In addition, the try-except-style is used to prevent the race-conditions inherent in some of the "look-before-you-leap" constructs. For example, testing os.path.exists results in information that may be out-of-date by the time you use it. Likewise, Queue.full returns information that may be stale. The try-except-else style will produce more reliable code in these cases.

"It my understanding that exceptions are not errors, they should only
be used for exceptional conditions"

In some other languages, that rule reflects their cultural norms as reflected in their libraries. The "rule" is also based in-part on performance considerations for those languages.

The Python cultural norm is somewhat different. In many cases, you must use exceptions for control-flow. Also, the use of exceptions in Python does not slow the surrounding code and calling code as it does in some compiled languages (i.e. CPython already implements code for exception checking at every step, regardless of whether you actually use exceptions or not).

In other words, your understanding that "exceptions are for the exceptional" is a rule that makes sense in some other languages, but not for Python.

"However, if it is included in the language itself, there must be a
good reason for it, isn't it?"

Besides helping to avoid race-conditions, exceptions are also very useful for pulling error-handling outside loops. This is a necessary optimization in interpreted languages which do not tend to have automatic loop invariant code motion.

Also, exceptions can simplify code quite a bit in common situations where the ability to handle an issue is far removed from where the issue arose. For example, it is common to have top level user-interface code calling code for business logic which in turn calls low-level routines. Situations arising in the low-level routines (such as duplicate records for unique keys in database accesses) can only be handled in top-level code (such as asking the user for a new key that doesn't conflict with existing keys). The use of exceptions for this kind of control-flow allows the mid-level routines to completely ignore the issue and be nicely decoupled from that aspect of flow-control.

There is a nice blog post on the indispensibility of exceptions here.

Also, see this Stack Overflow answer: Are exceptions really for exceptional errors?

"What is the reason for the try-except-else to exist?"

The else-clause itself is interesting. It runs when there is no exception but before the finally-clause. That is its primary purpose.

Without the else-clause, the only option to run additional code before finalization would be the clumsy practice of adding the code to the try-clause. That is clumsy because it risks
raising exceptions in code that wasn't intended to be protected by the try-block.

The use-case of running additional unprotected code prior to finalization doesn't arise very often. So, don't expect to see many examples in published code. It is somewhat rare.

Another use-case for the else-clause is to perform actions that must occur when no exception occurs and that do not occur when exceptions are handled. For example:

recip = float('Inf')
try:
recip = 1 / f(x)
except ZeroDivisionError:
logging.info('Infinite result')
else:
logging.info('Finite result')


Lastly, the most common use of an else-clause in a try-block is for a bit of beautification (aligning the exceptional outcomes and non-exceptional outcomes at the same level of indentation). This use is always optional and isn't strictly necessary.

A try block allows you to handle an expected error. The except block should only catch exceptions you are prepared to handle. If you handle an unexpected error, your code may do the wrong thing and hide bugs.

try

except

An else clause will execute if there were no errors, and by not executing that code in the try block, you avoid catching an unexpected error. Again, catching an unexpected error can hide bugs.

else

try

For example:

try:
try_this(whatever)
except SomeException as the_exception:
handle(the_exception)
else:
return something


The "try, except" suite has two optional clauses, else and finally. So it's actually try-except-else-finally.

else

finally

try-except-else-finally

else will evaluate only if there is no exception from the try block. It allows us to simplify the more complicated code below:

else

try

no_error = None
try:
try_this(whatever)
no_error = True
except SomeException as the_exception:
handle(the_exception)
if no_error:
return something


so if we compare an else to the alternative (which might create bugs) we see that it reduces the lines of code and we can have a more readable, maintainable, and less buggy code-base.

else

finally

finally will execute no matter what, even if another line is being evaluated with a return statement.

finally

It might help to break this down, in the smallest possible form that demonstrates all features, with comments. Assume this syntactically correct (but not runnable unless the names are defined) pseudo-code is in a function.

For example:

try:
try_this(whatever)
except SomeException as the_exception:
handle_SomeException(the_exception)
# Handle a instance of SomeException or a subclass of it.
except Exception as the_exception:
generic_handle(the_exception)
# Handle any other exception that inherits from Exception
# - doesn't include GeneratorExit, KeyboardInterrupt, SystemExit
# Avoid bare `except:`
else: # there was no exception whatsoever
return something()
# if no exception, the "something()" gets evaluated,
# but the return will not be executed due to the return in the
# finally block below.
finally:
# this block will execute no matter what, even if no exception,
# after "something" is eval'd but before that value is returned
# but even if there is an exception.
# a return here will hijack the return functionality. e.g.:
return True # hijacks the return in the else clause above


It is true that we could include the code in the else block in the try block instead, where it would run if there were no exceptions, but what if that code itself raises an exception of the kind we're catching? Leaving it in the try block would hide that bug.

else

try

try

We want to minimize lines of code in the try block to avoid catching exceptions we did not expect, under the principle that if our code fails, we want it to fail loudly. This is a best practice.

try

In Python, most exceptions are errors.

We can view the exception hierarchy by using pydoc. For example, in Python 2:

$ python -m pydoc exceptions


or Python 3:

$ python -m pydoc builtins


Will give us the hierarchy. We can see that most kinds of Exception are errors, although Python uses some of them for things like ending for loops (StopIteration). This is Python 3's hierarchy:

Exception

for

StopIteration

BaseException
Exception
ArithmeticError
FloatingPointError
OverflowError
ZeroDivisionError
AssertionError
AttributeError
BufferError
EOFError
ImportError
ModuleNotFoundError
LookupError
IndexError
KeyError
MemoryError
NameError
UnboundLocalError
OSError
BlockingIOError
ChildProcessError
ConnectionError
BrokenPipeError
ConnectionAbortedError
ConnectionRefusedError
ConnectionResetError
FileExistsError
FileNotFoundError
InterruptedError
IsADirectoryError
NotADirectoryError
PermissionError
ProcessLookupError
TimeoutError
ReferenceError
RuntimeError
NotImplementedError
RecursionError
StopAsyncIteration
StopIteration
SyntaxError
IndentationError
TabError
SystemError
TypeError
ValueError
UnicodeError
UnicodeDecodeError
UnicodeEncodeError
UnicodeTranslateError
Warning
BytesWarning
DeprecationWarning
FutureWarning
ImportWarning
PendingDeprecationWarning
ResourceWarning
RuntimeWarning
SyntaxWarning
UnicodeWarning
UserWarning
GeneratorExit
KeyboardInterrupt
SystemExit


A commenter asked:

Say you have a method which pings an external API and you want to handle the exception at a class outside the API wrapper, do you simply return e from the method under the except clause where e is the exception object?

No, you don't return the exception, just reraise it with a bare raise to preserve the stacktrace.

raise

try:
try_this(whatever)
except SomeException as the_exception:
handle(the_exception)
raise


Or, in Python 3, you can raise a new exception and preserve the backtrace with exception chaining:

try:
try_this(whatever)
except SomeException as the_exception:
handle(the_exception)
raise DifferentException from the_exception


I elaborate in my answer here.

upvoted! what do you usually do inside the handle part? lets say you have a method which pings an external API and you want to handle the exception at a class outside the API wrapper, do you simply return e from the method under the except clause where e is the exception object?
– PirateApp
Jul 14 at 12:27

@PirateApp thank you! no, don't return it, you should probably reraise with a bare raise or do exception chaining - but that's more on topic and covered here: stackoverflow.com/q/2052390/541136 - I'll probably remove these comments after I've seen you've seen them.
– Aaron Hall♦
Jul 14 at 12:40

raise

thank you so much for the details! going through the post now
– PirateApp
Jul 14 at 13:14

Python doesn't subscribe to the idea that exceptions should only be used for exceptional cases, in fact the idiom is 'ask for forgiveness, not permission'. This means that using exceptions as a routine part of your flow control is perfectly acceptable, and in fact, encouraged.

This is generally a good thing, as working this way helps avoid some issues (as an obvious example, race conditions are often avoided), and it tends to make code a little more readable.

Imagine you have a situation where you take some user input which needs to be processed, but have a default which is already processed. The try: ... except: ... else: ... structure makes for very readable code:

try: ... except: ... else: ...

try:
raw_value = int(input())
except ValueError:
value = some_processed_value
else: # no error occured
value = process_value(raw_value)


Compare to how it might work in other languages:

raw_value = input()
if valid_number(raw_value):
value = process_value(int(raw_value))
else:
value = some_processed_value


Note the advantages. There is no need to check the value is valid and parse it separately, they are done once. The code also follows a more logical progression, the main code path is first, followed by 'if it doesn't work, do this'.

The example is naturally a little contrived, but it shows there are cases for this structure.

Is it a good practice to use try-except-else in python?

The answer to this is that it is context dependent. If you do this:

d = dict()
try:
item = d['item']
except KeyError:
item = 'default'


It demonstrates that you don't know Python very well. This functionality is encapsulated in the dict.get method:

dict.get

item = d.get('item', 'default')


The try/except block is a much more visually cluttered and verbose way of writing what can be efficiently executing in a single line with an atomic method. There are other cases where this is true.

try

except

However, that does not mean that we should avoid all exception handling. In some cases it is preferred to avoid race conditions. Don't check if a file exists, just attempt to open it, and catch the appropriate IOError. For the sake of simplicity and readability, try to encapsulate this or factor it out as apropos.

Read the Zen of Python, understanding that there are principles that are in tension, and be wary of dogma that relies too heavily on any one of the statements in it.

You should be careful about using the finally block, as it is not the same thing as using an else block in the try, except. The finally block will be run regardless of the outcome of the try except.

In [10]: dict_ = "a": 1

In [11]: try:
....: dict_["b"]
....: except KeyError:
....: pass
....: finally:
....: print "something"
....:
something


As everyone has noted using the else block causes your code to be more readable, and only runs when an exception is not thrown

In [14]: try:
dict_["b"]
except KeyError:
pass
else:
print "something"
....:


I know that finally is always executed, and that is why it can be used to our advantage by always setting a default value, so in case of exception it is returned, if we do not want to return such value in case of exception, it is enough to remove the final block. Btw, using pass on an exception catch is something I would never ever do :)
– Juan Antonio Gomez Moriano
Apr 22 '13 at 4:55

@Juan Antonio Gomez Moriano , my coding block is for example purposes only. I probably would never use pass either
– Greg
Apr 22 '13 at 6:13

Whenever you see this:

try:
y = 1 / x
except ZeroDivisionError:
pass
else:
return y


Or even this:

try:
return 1 / x
except ZeroDivisionError:
return None


Consider this instead:

import contextlib
with contextlib.suppress(ZeroDivisionError):
return 1 / x


It does not answer my question, as that was simply an example my friend.
– Juan Antonio Gomez Moriano
Jan 17 '17 at 4:44

In Python, exceptions are not errors. They're not even exceptional. In Python, it's normal and natural to use exceptions for flow control. This is evidenced by the inclusion of contextlib.suppress() in the standard library. See Raymond Hettinger's answer here: stackoverflow.com/a/16138864/1197429 (Raymond is a core Python contributor, and an authority on all things Pythonic!)
– Rajiv Bakulesh Shah
Feb 14 '17 at 23:28

This is my simple snippet on howto understand try-except-else-finally block in Python:

def div(a, b):
try:
a/b
except ZeroDivisionError:
print("Zero Division Error detected")
else:
print("No Zero Division Error")
finally:
print("Finally the division of %d/%d is done" % (a, b))


Let's try div 1/1:

div(1, 1)
No Zero Division Error
Finally the division of 1/1 is done


Let's try div 1/0

div(1, 0)
Zero Division Error detected
Finally the division of 1/0 is done


OP, YOU ARE CORRECT. The else after try/except in Python is ugly. it leads to another flow-control object where none is needed:

try:
x = blah()
except:
print "failed at blah()"
else:
print "just succeeded with blah"


A totally clear equivalent is:

try:
x = blah()
print "just succeeded with blah"
except:
print "failed at blah()"


This is far clearer than an else clause. The else after try/except is not frequently written, so it takes a moment to figure what the implications are.

Just because you CAN do a thing, doesn't mean you SHOULD do a thing.

Lots of features have been added to languages because someone thought it might come in handy. Trouble is, the more features, the less clear and obvious things are because people don't usually use those bells and whistles.

Just my 5 cents here. I have to come along behind and clean up a lot of code written by 1st-year out of college developers who think they're smart and want to write code in some uber-tight, uber-efficient way when that just makes it a mess to try and read / modify later. I vote for readability every day and twice on Sundays.

You're right. That's totally clear and equivalent...unless it's your print statement that fails. What happens if x = blah() returns a str, but your print statement is print 'just succeeded with blah. x == %d' % x? Now you've got a TypeError being generated where you're not prepared to handle one; you're inspecting x = blah() to find the source of the exception, and it's not even there. I've done this (or the equivalent) more than once where the else would've kept me from making this mistake. Now I know better. :-D
– Doug R.
Mar 25 '15 at 20:30

print

x = blah()

str

print 'just succeeded with blah. x == %d' % x

TypeError

x = blah()

else

...and yes, you're right. The else clause isn't a pretty statement, and until you're used to it, it's not intuitive. But then, neither was finally when I first started using it...
– Doug R.
Mar 25 '15 at 20:32

else

finally

To echo Doug R., it isn't equivalent because exceptions during the statements in the else clause are not caught by the except.
– alastair
Apr 15 '15 at 8:57

else

except

if...except...else is more readable, otherwise you have to read "oh, after try block, and no exception, go to statement outside the try block", so using else: tends to semantically connect the syntax a bit better imo. Also, it's good practice to leave your untrapped statements outside of the initial try block.
– cowbert
May 5 '15 at 0:07

@DougR. "you're inspecting x = blah() to find the source of the exception", Having traceback why would you inspect the exception source from a wrong place?
– nehemiah
Oct 3 '17 at 2:23

x = blah()

traceback

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.