Should I test
if something is valid or just
try to do it and catch the exception?
- Is there any solid documentation saying that one way is preferred?
- Is one way more pythonic?
For example, should I:
if len(my_list) >= 4: x = my_list else: x = 'NO_ABC'
try: x = my_list except IndexError: x = 'NO_ABC'
PEP 20 says:
Errors should never pass silently.
Unless explicitly silenced.
Should using a
try instead of an
if be interpreted as an error passing silently? And if so, are you explicitly silencing it by using it in this way, therefore making it OK?
I’m not referring to situations where you can only do things 1 way; for example:
try: import foo except ImportError: import baz
You should prefer
if/else if that results in
- speed-ups (for example by preventing extra lookups)
- cleaner code (fewer lines/easier to read)
Often, these go hand-in-hand.
In the case of trying to find an element in a long list by:
try: x = my_list[index] except IndexError: x = 'NO_ABC'
the try, except is the best option when the
index is probably in the list and the IndexError is usually not raised. This way you avoid the need for an extra lookup by
if index < len(my_list).
Python encourages the use of exceptions, which you handle is a phrase from Dive Into Python. Your example not only handles the exception (gracefully), rather than letting it silently pass, also the exception occurs only in the exceptional case of index not being found (hence the word exception!).
The official Python Documentation mentions EAFP: Easier to ask for forgiveness than permission and Rob Knight notes that catching errors rather than avoiding them, can result in cleaner, easier to read code. His example says it like this:
Worse (LBYL ‘look before you leap’):
#check whether int conversion will raise an error if not isinstance(s, str) or not s.isdigit(): return None elif len(s) > 10: #too many digits for int conversion return None else: return int(s)
Better (EAFP: Easier to ask for forgiveness than permission):
try: return int(s) except (TypeError, ValueError, OverflowError): #int conversion failed return None
In this particular case, you should use something else entirely:
x = myDict.get("ABC", "NO_ABC")
In general, though: If you expect the test to fail frequently, use
if. If the test is expensive relative to just trying the operation and catching the exception if it fails, use
try. If neither one of these conditions applies, go with whatever reads easier.
except directly rather than inside an
if guard should always be done if there is any possibility of a race condition. For example, if you want to ensure that a directory exists, do not do this:
import os, sys if not os.path.isdir('foo'): try: os.mkdir('foo') except OSError, e print e sys.exit(1)
If another thread or process creates the directory between
mkdir, you’ll exit. Instead, do this:
import os, sys, errno try: os.mkdir('foo') except OSError, e if e.errno != errno.EEXIST: print e sys.exit(1)
That will only exit if the ‘foo’ directory can’t be created.
If it’s trivial to check whether something will fail before you do it, you should probably favor that. After all, constructing exceptions (including their associated tracebacks) takes time.
Exceptions should be used for:
- things that are unexpected, or…
- things where you need to jump more than one level of logic (e.g. where a
breakdoesn’t get you far enough), or…
- things where you don’t know exactly what is going to be handling the exception ahead of time, or…
- things where checking ahead of time for failure is expensive (relative to just attempting the operation)
Note that oftentimes, the real answer is “neither” – for instance, in your first example, what you really should do is just use
.get() to provide a default:
x = myDict.get('ABC', 'NO_ABC')
As the other posts mention, it depends on the situation. There are a few dangers with using try/except in place of checking the validity of your data in advance, especially when using it on bigger projects.
- The code in the try block may have a chance to wreak all sorts of havoc before the exception is caught – if you proactively check beforehand with an if statement you can avoid this.
- If the code called in your try block raises a common exception type, like TypeError or ValueError, you may not actually catch the same exception you were expecting to catch – it may be something else that raise the same exception class before or after even getting to the line where your exception may be raised.
e.g., suppose you had:
try: x = my_list[index_list] except IndexError: x = 'NO_ABC'
The IndexError says nothing about whether it occurred when trying to get an element of index_list or my_list.
Should using a try instead of an if be interpreted as an error passing silently? And if so, are you explicitly silencing it by using it in this way, therefore making it OK?
try is acknowledging that an error may pass, which is the opposite of having it pass silently. Using
except is causing it not to pass at all.
try: except: is preferred in cases where
if: else: logic is more complicated. Simple is better than complex; complex is better than complicated; and it’s easier to ask for forgiveness than permission.
What “errors should never pass silently” is warning about, is the case where code could raise an exception that you know about, and where your design admits the possibility, but you haven’t designed in a way to deal with the exception. Explicitly silencing an error, in my view, would be doing something like
pass in an
except block, which should only be done with an understanding that “doing nothing” really is the correct error handling in the particular situation. (This is one of the few times where I feel like a comment in well-written code is probably really needed.)
However, in your particular example, neither is appropriate:
x = myDict.get('ABC', 'NO_ABC')
The reason everyone is pointing this out – even though you acknowledge your desire to understand in general, and inability to come up with a better example – is that equivalent side-steps actually exist in quite a lot of cases, and looking for them is the first step in solving the problem.
Whenever you use
try/except for control flow, ask yourself:
- Is it easy to see when the
tryblock succeeds and when it fails?
- Are you aware of all side effects inside the
- Are you aware of all cases in which the
tryblock throws the exception?
- If the implementation of the
tryblock changes, will your control flow still behave as expected?
If the answer to one or more of these questions is ‘no’, there might be a lot of forgiveness to ask for; most likely from your future self.
I recently saw code in a larger project that looked like this:
try: y = foo(x) except ProgrammingError: y = bar(x)
Talking to the programmer it turned that the intended control flow was:
If x is an integer, do y = foo(x).
If x is a list of integers, do y = bar(x).
This worked because
foo made a database query and the query would be successful if
x was an integer and throw a
x was a list.
try/except is a bad choice here:
- The name of the exception,
ProgrammingError, does not give away the actual problem (that
xis not an integer), which makes it difficult to see what is going on.
ProgrammingErroris raised during a database call, which wastes time. Things would get truly horrible if it turned out that
foowrites something to the database before it throws an exception, or alters the state of some other system.
- It is unclear if
ProgrammingErroris only raised when
xis a list of integers. Suppose for instance that there is a typo in
foo‘s database query. This might also raise a
ProgrammingError. The consequence is that
bar(x)is now also called when
xis an integer. This might raise cryptic exceptions or produce unforeseeable results.
try/exceptblock adds a requirement to all future implementations of
foo. Whenever we change
foo, we must now think about how it handles lists and make sure that it throws a
ProgrammingErrorand not, say, an
AttributeErroror no error at all.
For a general meaning, you may consider reading Idioms and Anti-Idioms in Python: Exceptions.
In your particular case, as others stated, you should use
Return the value for key if key is in the
dictionary, else default. If default is not given, it defaults to
None, so that this method never raises a KeyError.