Ask for Forgiveness or Look Before You Leap?

“Ask for forgiveness” and “look before you leap” (sometimes also called “ask for permission”) are two opposite approaches to writing code. If you “look before you leap”, you first check if everything is set correctly, then you perform an action. For example, you want to read text from a file. What could go wrong with that? Well, the file might not be in the location where you expect it to be. So, you first check if the file exists:

Even if the file exists, maybe you don’t have permission to open it? So let’s check if you can read it:

But what if the file is corrupted? Or if you don’t have enough memory to read it? This list could go on. Finally, when you think that you checked every possible corner-case, you can open and read it:

Depending on what you want to do, there might be quite a lot of checks to perform. And even when you think you covered everything, there is no guarantee that some unexpected problems won’t prevent you from reading this file. So, instead of doing all the checks, you can “ask for forgiveness.”

With “ask for forgiveness,” you don’t check anything. You perform whatever action you want, but you wrap it in a try/catch block. If an exception happens, you handle it. You don't have to think about all the things that can go wrong, your code is much simpler (no more nested ifs), and you will usually catch more errors that way. That's why the Python community, in general, prefers this approach, often called "EAFP" - "Easier to ask for forgiveness than permission."

Here is a simple example of reading a file with the “ask for forgiveness” approach:

Here we are catching the IOError. If you are not sure what kind of exception can be raised, you could catch all of them with the BaseException class, but in general, it's a bad practice. It will catch every possible exception (including, for example, KeyboardInterrupt when you want to stop the process), so try to be more specific.

“Ask for forgiveness” is cleaner. But which one is faster?

“Ask For Forgiveness” vs “Look Before You Leap” — speed

Time for a simple test. Let’s say that I have a class, and I want to read an attribute from this class. But I’m using inheritance, so I’m not sure if the attribute is defined or not. I need to protect myself, by either checking if it exists (“look before you leap”) or catching the AttributeError ("ask for forgiveness"):

Let’s measure the speed of both functions. For benchmarking, I’m using the standard timeit module and Python 3.8. I describe my setup and some assumptions in the Introduction to the Writing Faster Python.

“Look before you leap” is around 30% slower (155/118≈1.314).

What happens if we increase the number of checks? Let’s say that this time we want to check for three attributes, not just one:

“Look before you leap” is now around 85% slower (326/176≈1.852). So the “ask for forgiveness” is not only much easier to read and robust but, in many cases, also faster. Yes, you read it right, “in many cases,” not “in every case!”

The main difference between “EAFP” and “LBYL”

What happens if the attribute is actually not defined? Take a look at this example:

The tables have turned. “Ask for forgiveness” is now over four times as slow as “Look before you leap” (562/135≈4.163). That’s because this time, our code throws an exception. And handling exceptions is expensive.

If you expect your code to fail often, then “Look before you leap” might be much faster.

Verdict

“Ask for forgiveness” results in much cleaner code, makes it easier to catch errors, and in most cases, it’s much faster. No wonder that EAFP (“Easier to ask for forgiveness than permission”) is such a ubiquitous pattern in Python. Even in the example from the beginning of this article (checking if a file exists with os.path.exists) - if you look at the source code of the exists method, you will see that it's simply using a try/except. "Look before you leap" often results in a longer code that is less readable (with nested if statements) and slower. And following this pattern, you will probably sometimes miss a corner-case or two.

As a rule of thumb — ask yourself: “Is it more common that this code will throw an exception or not?” Use “look before you leap” if you expect some problems (and if you can predict what those problems will be). Otherwise, use the “ask for forgiveness” for cleaner and faster code.

Originally published at https://switowski.com on August 19, 2020.