Why is checking os.path.exists() before open() weaker than catching FileNotFoundError?

### The shape of the problem A very common piece of transliterated Python looks like this: ```python import os if os.path.exists(path): with open(path) as handle: data = handle.read() else: data = None ``` The EAFP form is: ```python try: with open(path) as handle: data = handle.read() except FileNotFoundError: data = None ``` The second is not merely shorter. The first is *unreliable* in three distinct ways, and being able to separate them is what the question is really testing. ### 1. The check and the use are two operations with a gap between them `os.path.exists()` performs a `stat` on the path and returns a boolean about a moment that has already passed by the time the function returns. `open()` then performs its own, independent resolution of the same path. Between those two system calls the process can be descheduled for an arbitrarily long time, and the filesystem is shared, mutable, global state: another process, another thread, a cleanup job, a deploying container, or an operator can delete the file, rename it, replace it with a directory, or swap it for a symlink pointing elsewhere. The consequence is blunt: `os.path.exists()` returning `True` does not promise the following `open()` succeeds, and returning `False` does not promise it would have failed. You still have to handle `FileNotFoundError` on the `open()` line — which means the guard did not remove a failure path, it added a branch that gives false confidence. This is the general staleness property of any look-before-you-leap check over shared mutable state; on a filesystem the window is wide enough to hit in normal operation, not just under adversarial conditions. The fix is not "check twice" or "take a lock" — a lock in your process says nothing about other processes. The fix is to make the decision and the action *one* operation and let the kernel resolve it atomically, which is exactly what `open()` does. EAFP is not a style preference here; it is the only form that can be correct. ### 2. The guard answers a different question than you asked `os.path.exists()` follows symlinks and returns `False` if the underlying `stat` raises `OSError` — so it also answers `False` for a **broken symlink**, for a path inside a directory you lack execute permission on, and for a path whose name the operating system rejects. Your code then takes the "file is not there" branch for a situation that is actually "the file exists and you cannot see it", and the real cause is gone. Meanwhile `exists()` returns `True` for **directories**, so the guard passes and `open()` raises `IsADirectoryError` anyway. The exception carries the information the boolean threw away. `FileNotFoundError`, `PermissionError`, `IsADirectoryError` and `NotADirectoryError` are all `OSError` subclasses (split out into named classes in Python 3.3 by PEP 3151), each carrying `errno`, `strerror` and `filename`. Catching the one you can actually handle and letting the others propagate produces a much better failure than a boolean that collapses all of them into `False`. ### 3. Some intents cannot be expressed as check-then-act at all Consider "create this output file, but fail if it already exists" — the classic idempotence guard in a batch job. Written as `if not os.path.exists(out): open(out, 'w')`, two workers can both see `False` and both proceed, and the second silently truncates the first one's work. There is no arrangement of checks that fixes it, because the check and the create are separate. The correct form pushes the whole decision into one kernel call: ```python fd = os.open(out, os.O_CREAT | os.O_EXCL | os.O_WRONLY) ``` `os.O_EXCL` makes creation fail with `FileExistsError` if the path already exists, atomically. Similarly, `os.replace()` gives an atomic rename over an existing destination, which is how you publish a finished file without a window where a reader can see a half-written one: write to a temporary name, then replace. ### What good code actually looks like Attempt the operation; catch the specific `OSError` subclasses you have a real response for; keep the `try` around only the call that can fail, so a bug in your parsing code is not classified as a missing file: ```python try: handle = open(path, 'rb') except FileNotFoundError: return None with handle: return parse(handle) ``` When the intent truly is "remove this if it happens to be there", `contextlib.suppress(FileNotFoundError)` states that intent in one line and names the exception it is ignoring, which is far better than a bare `except: pass`. ### Where a check is still fine LBYL on the filesystem is not banned. A pre-flight check at startup — "does the config directory exist, is the output directory writable" — is a legitimate use: you are producing a clear diagnostic early, not relying on the answer to make a later operation safe. The rule is that a check may *inform* you; it may never be the thing that makes the subsequent call correct.