Better to 'try' something and catch the ex

问题:

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[3]
else:
    x = \'NO_ABC\'

Or:

try:
    x = my_list[3]
except IndexError:
    x = \'NO_ABC\'

---

Some thoughts...
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

回答1:

You should prefer try/except over if/else if that results in

• speed-ups (for example by preventing extra lookups)
• cleaner code (less lines/easier to read)

Often, these go hand-in-hand.

---

speed-ups

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(mylist).

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!).

---

cleaner code

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(str)

Better (EAFP: Easier to ask for forgiveness than permission):

try:
    return int(str)
except (TypeError, ValueError, OverflowError): #int conversion failed
    return None

回答2:

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.

回答3:

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:

1. things that are unexpected, or...
2. things where you need to jump more than one level of logic (e.g. where a break doesn\'t get you far enough), or...
3. things where you don\'t know exactly what is going to be handling the exception ahead of time, or...
4. 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\')

回答4:

Using try and 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 isdir and 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.

回答5:

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?

Using 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.

Using 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.

回答6:

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[3]]
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.

回答7:

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 dict.get():

get(key[, default])

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.

回答8:

Whenever you use try/except for control flow, ask yourself:

1. Is it easy to see when the try block succeeds and when it fails?
2. Are you aware of all side effects inside the try block?
3. Are you aware of all cases in which the try block throws the exception?
4. If the implementation of the try block 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.

---

An example. 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)

and 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 ProgrammingError if x was a list.

Using try/except is a bad choice here:

1. The name of the exception, ProgrammingError, does not give away the actual problem (that x is not an integer). That makes it difficult to figure out what is going on.
2. The ProgrammingError is raised during a database call, which unnecessarily wastes time. Things would get truly horrible if it turned out that foo writes something to the database before it throws an exception, or alters the state of some other system.
3. It is unclear whether every ProgrammingError is caused by x being a list. 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 if x is an integer. This might raise cryptic exceptions or produce unforeseeable results.
4. The try/except block 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 ProgrammingError and not, say, an AttributeError or no error at all.