Python Context Managers: Make Cleanup Part of the Control Flow

Reviewed October 8, 2026. Examples target Python 3.12 and use local temporary resources.

A successful script can hide a resource-management bug. A file closes because the program ends, a lock eventually disappears with its process, or a connection remains open long enough for a demonstration to finish. The bug becomes visible when the same code runs repeatedly, fails halfway through, or is reused inside a longer application. Cleanup needs an explicit place in the program's control flow.

The with statement gives that place a standard protocol. A context manager enters a context, supplies an optional value, and handles exit after the body completes or raises. It is useful for resources and temporary state, but it does not automatically make operations transactional or errors harmless. The manager's implementation determines those behaviors.

1. Separate acquisition, use, and release

A resource owner is responsible for acquiring and releasing the resource. A borrower may use it while the owner guarantees its lifetime. This distinction matters when designing a function that accepts either a path or an already-open stream. A function that opens its own file normally closes it; a function borrowing a caller's stream should not unexpectedly close that stream unless the API explicitly says ownership transfers.

Opening a file in a with block makes that ownership visible. The file is available in the body and is closed on exit during normal execution, including when an exception leaves the body. This does not undo bytes already written. Closing and rollback are different operations, and a context manager only provides the latter if its documented implementation actually does so.

2. Observe cleanup on the failure path

This example models a resource with a small dictionary so its lifecycle is easy to inspect. It avoids depending on garbage collection or process shutdown.

from contextlib import contextmanager

events = []

@contextmanager
def owned_resource():
    resource = {"closed": False}
    events.append("acquired")
    try:
        yield resource
    finally:
        resource["closed"] = True
        events.append("released")

try:
    with owned_resource() as handle:
        events.append("used")
        raise ValueError("synthetic failure")
except ValueError as error:
    assert str(error) == "synthetic failure"
    events.append("caught by caller")

assert handle["closed"] is True
assert events == ["acquired", "used", "released", "caught by caller"]
print(events)

The decorator turns a generator function into a context-manager factory. Acquisition happens before yield; the body uses the yielded value; exit resumes the generator. The finally clause handles release even when the body raises. A generator-based context manager must yield exactly once for each use. A general iterator that yields many records is a different interface.

The exception reaches the caller because the manager does not consume it. If a manager catches an error only to add context or log it, it must re-raise when propagation is intended. Accidentally catching without re-raising can turn a failed operation into apparent success. Treat that decision as part of the API rather than a cosmetic detail.

3. Understand what the protocol does not guarantee

The with syntax alone cannot establish any row in the last column. For example, the Python SQLite connection context manager manages open transactions, but does not close the connection. A separate close or contextlib.closing can supply that lifetime boundary. Readers should inspect the particular manager's documentation rather than infer its behavior from syntax.

An exit operation can itself fail. A file flush may report an I/O error, or custom cleanup may raise. Such a failure can replace the exception currently being propagated, with exception chaining providing context. Keep cleanup small, avoid unnecessary new work in it, and decide how the application will report multiple failures. Do not add a broad catch that discards the original problem merely to produce an apparently clean exit.

4. Manage a dynamic collection with ExitStack

Nested with statements work well when the number of resources is fixed. When a function opens a configurable number of files, ExitStack records successful acquisitions and releases them in reverse order. If a later acquisition fails, earlier resources already registered with the stack still receive cleanup.

from contextlib import ExitStack
from pathlib import Path
from tempfile import TemporaryDirectory

with TemporaryDirectory() as folder:
    root = Path(folder)
    (root / "a.txt").write_text("alpha", encoding="utf-8")
    handles = []
    try:
        with ExitStack() as stack:
            for name in ["a.txt", "missing.txt"]:
                handle = stack.enter_context(
                    (root / name).open(encoding="utf-8")
                )
                handles.append(handle)
    except FileNotFoundError:
        pass
    else:
        raise AssertionError("The missing input must fail.")
    assert len(handles) == 1
    assert handles[0].closed
    print("Previously opened input was closed after acquisition failed.")

The first file opens successfully. The second file is absent, so opening it raises before its handle can be registered. Exiting the stack closes the first file. The test checks the expected exception type and the earlier handle's state; it does not rely on a cleanup side effect happening sometime later.

Use the same approach for cleanup callbacks when a resource lacks the context-manager protocol. Register a callback only after acquisition succeeds, and ensure the callback refers to the resource actually acquired. Reverse release order supports dependencies, such as closing a child handle before disposing of its enclosing resource.

5. Borrowed resources and temporary state

nullcontext can represent a borrowed resource that needs no additional entry or exit action. This can simplify a documented path-or-stream API, but accepting both kinds of input also introduces validation and typing decisions. Avoid closing a caller's stream just because doing so is convenient in one implementation. Test that borrowed resources remain usable after the call.

Some context managers temporarily change global process state. Redirecting standard output and changing the working directory are examples. They can be useful in small scripts, but concurrent code may observe those changes. A context manager restores state on exit; it does not make a global change invisible to other threads or tasks while the body runs. Prefer explicit output streams and absolute paths when the function may be reused concurrently.

Likewise, suppress only errors that are expected and compatible with the result. Ignoring a missing temporary file during cleanup can be reasonable. Ignoring all exceptions from a data-writing operation can conceal a failed export. Narrow error types and narrow protected blocks make that distinction reviewable.

6. Test lifecycle behavior as part of correctness

A useful lifecycle test covers successful use, failure inside the body, and failure while acquiring a later resource. It verifies both the returned behavior and the release order where order matters. A value-only test may pass while leaking handles or releasing resources too early.

For practice, add a second successful file to the ExitStack example, then deliberately raise inside the body. Confirm that both handles close and that the caller sees the exception. Next, wrap a caller-owned stream with a documented borrowing function and check that it stays open. These small experiments establish ownership more clearly than a blanket instruction to use with everywhere.

Sources and scope

• Python 3.12: contextlib and ExitStack.
• Python 3.12: the with statement.
• Python 3.12: SQLite connection context manager.

The examples exercise ordinary Python control flow. They do not simulate power loss, abrupt process termination, asynchronous cancellation, or a production database transaction.