Errors vs Logging: The Two-Channel Mental Model

Python programs communicate two fundamentally different kinds of information when something goes wrong, and this section covers both under one label - "errors and logging" - which can blur an important distinction.

Exceptions are a control-flow channel: raising one immediately stops normal execution and unwinds the call stack, searching for a handler, until something catches it or the program crashes.

Logging is an observability channel: a log call is a side effect that records what happened, and it never changes what code executes next, whether or not anyone is watching the logs.

Exceptions Basics and The logging Module each cover one channel hands-on; Raising & Chaining, Custom Exception Hierarchies, Exception Groups & except*, and Structured & Contextual Logging each go deep on one mechanism within a channel.

This page is the layer underneath all of them: why these two channels exist separately, and how they meet at the boundaries of a program.

Summary

• Exceptions control what code runs next by unwinding the call stack; logging records what happened without affecting what runs next - two channels, not one.
• Insight: Conflating them leads to the two most common failure modes in this area - exceptions used purely for logging noise, and logs used as a substitute for actually handling a failure.
• Key Concepts: control-flow channel, observability channel, exception hierarchy, exception chaining, exception group, structured logging.
• When to Use: Deciding whether a failure should stop execution (raise), be recorded for later analysis (log), or both; designing a custom exception hierarchy; choosing what belongs in a log record versus an exception message.
• Limitations/Trade-offs: Handling both channels correctly at every boundary is extra code - swallowing an exception silently or logging without ever raising both feel like shortcuts, and both quietly lose information a future debugging session will need.
• Related Topics: the try/except/finally model, custom exception design, the standard logging module, retry and backoff strategies.

Foundations

An exception's job is to interrupt normal execution the instant something makes continuing unsafe or meaningless - dividing by zero, a missing file, invalid input.

raise throws control immediately up the call stack, skipping the rest of the current function and every calling function in turn, until a matching except block catches it or the program terminates with a traceback.

That upward search is the mechanism: Python doesn't ask every function along the way whether it wants to handle the exception, it simply keeps unwinding until something explicitly says it will.

A logging call is architecturally nothing like that.

logger.error("payment failed", extra={"order_id": order_id}) runs, writes a record somewhere (console, file, a log aggregator), and returns - the next line of code executes exactly as if the call had been a no-op, because logging carries no control-flow meaning of its own.

The useful analogy: an exception is a fire alarm that stops the building's normal operations until someone responds, while a log line is a security camera recording that plays no active role in what happens next, only in what you can review afterward.

def charge(amount: float) -> None:
    if amount < 0:
        logger.error("invalid charge amount=%s", amount)  # observability: just records
        raise ValueError("amount must be non-negative")    # control flow: actually stops execution

That single function shows both channels doing their separate jobs at once - the log line documents the failure for whoever reviews it later, and the raise is what actually prevents the invalid charge from proceeding.

Mechanics & Interactions

The exception hierarchy exists to let a caller catch a family of related failures without enumerating every specific subtype, which is a design decision entirely internal to the control-flow channel.

Catching OSError instead of FileNotFoundError, PermissionError, and IsADirectoryError separately works because all three inherit from OSError - the hierarchy is a taxonomy built for the unwinding search to match against, not a logging concern at all.

Exception chaining (raise NewError(...) from original) extends this same control-flow model across a translation boundary: when low-level code raises one exception and a higher layer wants to raise a different, more meaningful one, chaining preserves the original as __cause__ so nothing about why the new exception happened is lost, even though the exception's type changed.

Exception groups (ExceptionGroup, except*, 3.11+) extend the same unwinding model from "exactly one exception in flight" to "several unrelated exceptions in flight at once" - the natural result of, say, a task group where multiple concurrent operations each fail independently, and none of them should be silently dropped in favor of just the first one caught.

Logging's mechanics run on an entirely separate axis: a Logger doesn't unwind anything, it hands a record to handlers, which route it to formatters, which decide how the final text or JSON looks - a pipeline about where information goes, with no relationship to what code runs next.

Control-flow channel                    Observability channel
---------------------------------       ---------------------------------
raise -> unwind call stack -> except      logger.error(...) -> handler -> formatter -> output
(stops normal execution)                  (side effect only, execution continues)

Where the two channels genuinely interact is at boundaries: a function often logs an error (for the record) and then re-raises or raises a translated exception (for control flow), because a caller several layers up needs to react to the failure, while an operator watching logs needs to see it happened at all - neither channel alone delivers both outcomes.

Advanced Considerations & Applications

At scale, this two-channel model explains why structured logging matters more than it first appears to.

A plain string log message ("payment failed for order 123") is fine for a human reading a terminal, but useless for a system that needs to query "show me every failed payment in the last hour grouped by error code" - structured logging attaches machine-queryable fields (order_id, error_code, correlation_id) to the same record, which is what makes the observability channel actually operable at production scale rather than just a scrollback buffer.

Retries and backoff sit squarely at the intersection of both channels: a transient failure should be logged (so operators see it happening), retried a bounded number of times (control flow deciding whether to try again), and finally either succeed silently or escalate to a real exception if retries are exhausted - conflating "log it" with "we handled it" is exactly how a service ships that silently retries forever without anyone noticing the underlying dependency is down.

Warnings (the warnings module) are a third, smaller channel worth distinguishing from both: a DeprecationWarning is neither a control-flow interruption nor a persistent operational log - it's a one-time-by-default notice aimed at developers during development and testing, filtered differently from both exceptions and application logs.

Common Misconceptions

• "Logging an error means the error was handled." A log call is a side effect with no bearing on control flow - if nothing also raises, retries, or otherwise reacts, the failure has been recorded but not actually dealt with.
• "Catching Exception broadly is safer because it prevents crashes." It prevents visible crashes, but it also silently absorbs bugs the exception hierarchy was designed to let specific handlers catch - narrower catches are usually the safer choice.
• "raise ... from is just cosmetic traceback formatting." It sets __cause__, an actual attribute other tools and future debugging can inspect - it preserves real causal information, not just prettier output.
• "Exception groups are for concurrency code only." except* and ExceptionGroup model "more than one unrelated failure happened in one operation," which shows up in batch validation and aggregation code even without any concurrency involved.
• "More logging is always better." Excess or unstructured logging raises noise and cost without raising signal - the goal is queryable, actionable records, not maximum volume.

FAQs

Related

• Exceptions Basics - the control-flow channel's core syntax
• The logging Module - the observability channel's core API
• Raising & Chaining - preserving causality across translation boundaries
• Custom Exception Hierarchies - designing the taxonomy callers catch against
• Exception Groups & except* - more than one failure in flight at once
• Structured & Contextual Logging - making the observability channel queryable

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+.