Why is "Easier to Ask Forgiveness than it is to get Permission" (EAFP) considered good practice in Python? As a programming novice I have the impression that using many try...except routines will rather lead to bloated and less readable code than compared to using other checks.
What is the advantage of the EAFP approach?
NB: I know there are similar questions here, but they mostly refer to some specific example, while I am more interested in the philosophy behind the principle.
LBYL, the counter approach to EAFP doesn't have anything to do with assertions, it just means that you add a check before you try to access something that might not be there.
The reason that Python is EAFP is that unlike other languages (Java for example) - in Python catching exceptions is relatively inexpensive operation, and that's why you're encouraged to use it.
Example for EAFP:
try:
snake = zoo['snake']
except KeyError as e:
print "There's no snake in the zoo"
snake = None
Example for LBYL:
if 'snake' in zoo:
snake = zoo['snake']
else:
snake = None
You are mixing two things here: Assertions and EAFP-based logic.
Assertions are used to validate the contract of functions, i.e. its pre- and postconditions and sometimes also its invariants. They ensure that a function would be used in the way it should be used. They are not for code flow though, since they completely interrupt the execution on error. A common example is a check for None arguments in function calls.
In Python, you usually avoid using assertions too much. In general, you should expect users of your code to use it correctly. For example, if you document a function to take an argument that is not None, then it’s not necessary to have an assert that validates that. Instead, just expect that there is a value. If there is an error because of a None value, then it will bubble up anyway, so the user knows that they did something wrong. But you shouldn’t have to check everything all the time.
Now, EAFP is something different. It’s used in control flow, or rather, it avoids additional control flow in favor of expecting things to be correct and catching exceptions instead if they are not. A common example that shows the difference is a key access in a dictionary:
# LBYL
if key in dic:
print(dic[key])
else:
handleError()
# EAFP
try:
print(dic[key])
except KeyError:
handleError()
Now this looks very similar, although you should keep in mind that the LBYL solution checks the dictionary twice. As with all code that catches exceptions, you should only do it if the non-existance of a key is the exceptional case. So if usually, the supplied key is excepted to be in the dictionary, then it’s EAFP and you should just access it directly. If you don’t expect the key to be present in the dictionary, then you should probably check its existance first (while exceptions are cheaper in Python, they are still not free, so keep them for exceptional cases).
A benefit of EAFP here would also be that deeper down in the logic of your library or application, where the key comes from above, you can just assume that a valid key was passed here. So you don’t need to catch exceptions here but just let them bubble up to a higher point in your code where you can then handle the error. That allows you to have lower-level functions completely free of these kind of checks.
Nice question! There are very few questions in StackOverflow asking about "the philosophy behind the principle".
Regarding to the EAFP definition in Python glossary, I would even go further and say its mentioning of "caches exceptions if the assumption proves false" is somewhat misleading in this context. Because, let's face it, the following 2nd code snippet does NOT look more "clean and fast" (a term used in the aforementioned definition). No wonder the OP asked this question.
# LBYL
if key in dic:
print(dic[key])
else:
handleError()
# EAFP
try:
print(dic[key])
except KeyError:
handleError()
I would say, the real moment when EAFP shines, is that you do NOT write try ... except ... at all, at least not in most of your underlying code base. Because, the first rule of exception handling: do not do exception handling. With that in mind, now, let's rewrite the 2nd snippet into this:
# Real EAFP
print(dic[key])
Now, isn't that real EAFP approach clean and fast?
I'll expand on the answer from @RayLuo.
The problem with LBYL is, it actually doesn't work in general. Unless you have a single-threaded application, there's always a possible race condition:
# LBYL
if key in dic:
# RACE CONDITION
print(dic[key])
else:
handleError()
# EAFP
try:
print(dic[key])
except KeyError:
handleError()
A key can be added to the dict between the if check and and print. That doesn't sound incredibly likely in this particular case. However it's much more likely if the check you're making is against a DB, API, or any external data source that can change asynchronously with your application data.
That means the "right" way to implement LBYL is:
if key in dic:
try:
print(dic[key])
except KeyError:
handleError()
else:
handleError()
Note the try / except clause is exactly the same as
the EAFP approach.
Since you have to handle the exception EAFP-style even when using the LBYL approach, you might as well use the EAFP approach in the first place.
The only circumstance in which I'd use the if check is if the action that follows (print in this case) is very expensive / time-consuming to initiate. That would be rare and not a reason to use the if check every time.
Bottom line: LBYL doesn't work in the general case, but EAFP does. Good developers focus on general solution patterns they can use confidently across a wide range of problems. Learn to use EAFP consistently.
