Python developers love the phrase "it is easier to ask forgiveness than permission". In Python, that style is usually called EAFP: try the operation first, then handle the failure if it actually happens.

Instead of surrounding every line with defensive checks, we keep the business logic visible and move the fallback path into except.

def safe_divide(numerator: float, denominator: float) -> float | None:
    try:
        return numerator / denominator
    except ZeroDivisionError:
        print("Division by zero is not allowed.")

The important action, division, appears immediately. The reader does not need to walk through a list of preconditions before understanding what the function wants to do.

The Myth of Expensive try-except

Developers coming from C++ or Java sometimes assume a try block automatically makes Python slower. That is not how modern Python behaves on the normal path.

Python compiles source code into bytecode and keeps exception metadata for the protected region. While the code runs without an exception, the interpreter can continue through the main instructions without constantly paying for the handler.

The cost appears when an exception is actually raised. At that moment Python has to locate the handler, adjust the stack, jump into the except block, and build the error context.

So the practical rule is simple: a try block is cheap when the failure is rare, but repeatedly raising exceptions in a hot loop can become expensive.

A Quick Bytecode Experiment

You can inspect the structure with dis:

import dis

code = """
try:
    value = int("not-a-number")
except ValueError:
    value = 0
"""

dis.dis(code)

When you disassemble the snippet, you will see the bytecode for the protected block plus exception handling information that tells Python where to jump if a ValueError is raised.

No exception means the normal path stays direct. An exception means Python switches to the recovery path you wrote.

When an if-check Wins

EAFP is strongest when failures are unusual. If the "failure" happens half the time, exceptions stop being exceptional and become overhead.

A file-processing job is a good example. If you scan millions of paths and many of them are missing, an explicit check can be clearer and faster:

from pathlib import Path


def read_if_exists(path: str) -> str | None:
    p = Path(path)
    if not p.is_file():
        return None
    return p.read_text()

In this case a missing file is part of the normal workload. Avoiding a storm of FileNotFoundError exceptions keeps the loop calmer.

What Happens Inside

Here is the simplified flow:

1. Python compiles source code into bytecode and records which handler owns which bytecode range.
2. The interpreter executes the normal bytecode path.
3. If an error appears, Python looks up the current bytecode position in the exception data.
4. Python trims irrelevant stack state and jumps to the matching handler.
5. If no handler is found, the exception bubbles upward until something catches it or the program exits with a traceback.

That is why exception handling is pleasant for rare failures and noisy for frequent ones.

Real-World Example: Dictionaries

Dictionary lookups are a classic EAFP fit when misses are uncommon:

def price_for(item: str, catalog: dict[str, float]) -> float | None:
    try:
        return catalog[item]
    except KeyError:
        print(f"Item {item!r} is not in the catalog.")

In a normal shop catalog, most lookups should succeed. A missing product is genuinely exceptional, so try-except keeps the happy path compact.

Real-World Example: Network Requests

Network code is another place where try-except keeps intent readable:

import requests


def fetch_json(url: str) -> dict | None:
    try:
        response = requests.get(url, timeout=3)
        response.raise_for_status()
        return response.json()
    except (requests.RequestException, ValueError):
        print("Unable to fetch or parse data.")

The internet is unreliable, but success is still the path you want readers to see first. The recovery logic stays grouped in one place.

Takeaways

Use try-except when the failure is rare and the direct action communicates the function clearly.

Use an if check when the condition is common, expected, or cheap to test before doing the work.

There is no universal winner. In 2026, good Python error handling is still about matching the code shape to the probability of failure and the cost of recovery.