EAFP vs LBYL

### The two idioms Every language has to answer the question "what do I do about an operation that might not be valid right now?" Python has two named answers, and the acronyms show up constantly in code review. **LBYL — Look Before You Leap.** Test the precondition, then act: ```python if isinstance(raw, str) and raw.isdigit(): port = int(raw) else: port = 8080 ``` **EAFP — Easier to Ask Forgiveness than Permission.** Act, and handle the exception if the precondition did not hold: ```python try: port = int(raw) except (TypeError, ValueError): port = 8080 ``` Both are legal Python. The second is the idiomatic one, and being able to say *why* is the point of the question — an interviewer is checking whether you write Python or transliterated Java/C, where exceptions are reserved for the exceptional and every call is guarded. ### Why Python leans EAFP **The failure signal already exists, and it is specific.** Python's data model is defined in terms of exceptions: a missing mapping key raises `KeyError`, a missing attribute raises `AttributeError`, an unparseable value raises `ValueError`, a wrong type raises `TypeError`, an absent file raises `FileNotFoundError`. Every one of those carries what failed and, in a traceback, exactly where. An LBYL guard throws that away and re-derives the same answer with a weaker test. **The guard can be wrong, and it can drift.** This is the strongest argument, and the example above shows it: `str.isdigit()` is *not* the precondition of `int()`. `int('-1')` succeeds and `'-1'.isdigit()` is `False`, so the LBYL version silently returns the default for a perfectly good input; `' 7 '.isdigit()` is also `False` while `int(' 7 ')` is `7`. The guard is an approximation of the operation's real rules, written by hand, and every approximation is a bug waiting for an input. Even when the guard starts correct, it lives in a different line from the call, so a later change to the call — a different parser, an extra accepted format — does not automatically update it. A `try` block cannot drift from the statement inside it. **Duck typing makes exhaustive guards impossible.** Python code routinely accepts "anything that behaves like X". You cannot enumerate the types that support an operation, so checking types up front narrows what your function accepts for no benefit. Attempting the operation accepts everything that actually works. **A guard can go stale between the check and the use.** The state you tested is not necessarily the state you act on: another thread, another process, or a callback can change it in between, and for a dynamic attribute or a filesystem path the window is real. The guard then gives false confidence — you still need the exception handler, so you have written two failure paths instead of one. ### Doing EAFP properly EAFP is not an excuse for a blanket handler. Three rules make it disciplined rather than sloppy: 1. **Catch the specific exception**, or an explicit tuple of them, never bare `except:` and rarely `except Exception:`. A handler that catches everything catches your own bugs — `NameError`, `AttributeError` from a typo — and reports them as the expected condition. 2. **Keep the `try` block small.** Only the call that can raise belongs inside it. A wide `try` accidentally captures a failure from an unrelated line and misclassifies it. 3. **Handle, don't discard.** A handler that does nothing but `pass` converts a failure into a silent wrong answer. ### When LBYL is the right call EAFP is the default, not a law. Prefer a check when the operation is **expensive or partially irreversible** — you do not want to write half a file, spend a network round trip, or mutate shared state and then unwind. Prefer it when the failure is the **common case rather than the exception**, so the work of raising and unwinding happens on most iterations of a loop. Prefer it at a **validation boundary**, where you want to collect several problems and report them all to a user rather than abort on the first. And prefer it when the exception is **ambiguous** — if two very different causes raise the same exception type, a cheap up-front check can separate them. ### A note on speed A common objection is "but exceptions are slow, so I should guard." On modern CPython, *entering* a `try` block costs nothing at runtime: since Python 3.11 the compiler emits a zero-cost exception table instead of a setup instruction, so the successful path is as fast as no `try` at all. Cost is paid only when an exception is actually raised and unwound. That flips the naive intuition: EAFP is the cheaper idiom precisely when failures are rare, which is the normal case, and LBYL becomes the performance argument only when failures dominate.