13.6. Principles for using Exceptions¶
There are many bad examples of exception use on the Internet. The purpose
of an exception is to modify the flow-of-control, not to catch simple errors.
If your try: except: block is in the same function that raises the
exception, you are probably mis-using exceptions.
Principle 1:
If a condition can be handled using the normal flow-of-control, don’t use an exception!
Example 1:
DON’T DO THIS: |
When you can just as easily test for no items in the list doing this: |
try:
average = sum(a_list) / len(a_list)
except ZeroDivisionError:
average = 0
|
if len(a_list) > 0:
average = sum(a_list) / len(a_list)
else:
average = 0
|
Example 2:
DON’T DO THIS: |
When you can just as easily test for a valid index doing this: |
try:
value = my_list[index]
except IndexError:
value = -1
|
if 0 <= index < len(my_list):
value = my_list[index]
else:
value = -1
|
Example 3:
DON’T DO THIS: |
When you can just as easily test to see if the key is valid doing this: |
try:
value = my_dictionary[key]
except KeyError:
value = -1
|
if key in my_dictionary.keys():
value = my_dictionary[key]
else:
value = -1
|
Principle 2:
If you call a function that potentially raises exceptions, and you can do
something appropriate to deal with the exception, then surround the code
that contains the function call with a try: except: block.
Example: Suppose you have a function that reads a file to set the state of an application when it starts up. You should catch any errors related to reading the file and set the state of the application to default values if they can’t be set from the file.
try:
load_state('previous_state.txt')
except OSError:
set_state_to_defaults()
Principle 3:
If you call a function that potentially raises exceptions, and you can’t do anything meaningful about the conditions that are raised, then don’t catch the exception message(s).