EAFP vs LBYL

Python favors EAFP (Easier to Ask Forgiveness than Permission): try the operation and handle failure with exceptions. LBYL (Look Before You Leap) checks conditions first. Both are valid; EAFP is idiomatic when the happy path is common and failures are exceptional.

Recipe

Quick-reference recipe card - copy-paste ready.

# EAFP - try, then handle
try:
    value = mapping[key]
except KeyError:
    value = default
 
# LBYL - guard, then act
if key in mapping:
    value = mapping[key]
else:
    value = default

When to reach for this:

• EAFP when the success path dominates and a failed lookup is rare
• LBYL when failure is expected and you want to avoid exception overhead
• EAFP when checking all preconditions is harder than trying (duck typing)
• LBYL in tight loops where exceptions would fire thousands of times per second
• EAFP when multiple failure modes collapse into one except block

Working Example

A parser accepts dict or object inputs using EAFP duck typing, with LBYL only for cheap type branching.

from typing import Any
 
def get_name(record: Any, default: str = "unknown") -> str:
    """Extract a name from a dict-like or attribute-based record."""
    if isinstance(record, dict):
        return record.get("name", default)
    try:
        return record.name
    except AttributeError:
        return default
 
def parse_user_id(raw: str) -> int:
    try:
        return int(raw)
    except ValueError as exc:
        raise ValueError(f"invalid user id: {raw!r}") from exc
 
samples = [
    {"name": "Ada"},
    type("User", (), {"name": "Grace"})(),
    object(),
]
 
for sample in samples:
    print(get_name(sample))
 
print(parse_user_id("42"))

What this demonstrates:

• Dict path uses .get() (LBYL-style guard via API) - no exception for missing keys
• Attribute access uses EAFP - one try covers many object shapes
• Re-raising with from exc preserves the original traceback chain
• Duck typing avoids hasattr chains that race with dynamic attributes

Deep Dive

How It Works

• EAFP executes the operation; Python raises a specific exception on failure
• LBYL evaluates predicates (in, isinstance, hasattr) before the operation
• Exception handling has a small setup cost; in hot loops, millions of exceptions hurt
• try/except around the success path keeps code linear and readable
• Multiple guard clauses (LBYL) often duplicate the work the operation would do anyway

EAFP vs LBYL at a Glance

Python Notes

# Prefer EAFP for file existence when you will open immediately anyway
try:
    with open(path) as f:
        data = f.read()
except FileNotFoundError:
    data = ""
 
# Prefer LBYL when failure is the norm (scanning optional keys)
for key in optional_keys:
    if key in cache:
        process(cache[key])

Gotchas

• TOCTOU with LBYL - checking key in dict then dict[key] can fail if another thread deletes the key. Fix: use EAFP (try/except KeyError) or .get().
• Bare except: - EAFP tempts catching everything. Fix: catch specific exceptions (KeyError, ValueError, AttributeError).
• hasattr + getattr duplication - if hasattr(x, "foo"): x.foo calls getattr twice. Fix: use EAFP with try/except AttributeError.
• Exception-driven control flow in loops - parsing every line with int() in a tight loop is slow when most lines fail. Fix: pre-filter with regex or LBYL validation.
• Swallowing exceptions - empty except: pass hides bugs. Fix: log, re-raise, or return a sentinel with explicit typing.

Alternatives

FAQs

Related

• Context Managers as a Pattern - EAFP for resource cleanup
• Null Object & Sentinels - avoid ambiguous missing values
• Pythonic Patterns Basics - section overview
• Common Anti-Patterns - when guards go wrong

Stack versions: This page was written for Python 3.14.0 (stable 3.14, maintenance 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, and uv 0.6+.