Python __exit__ Returning True — The Silent Bug Pattern

Here's a skeleton implementation for a file-like resource. Notice that __exit__ receives three positional arguments, and if you omit one, Python raises a TypeError at runtime — not at definition time. Many teams discover this in production when an unexpected exception triggers the else branch.

import io

class ManagedFile:
    def __init__(self, filename: str, mode: str = 'r'):
        self._filename = filename
        self._mode = mode
        self._file = None

    def __enter__(self):
        self._file = open(self._filename, self._mode)
        return self._file

    def __exit__(self, exc_type, exc_val, exc_tb):
        if self._file:
            self._file.close()
        # Do not suppress exceptions
        return False

# Usage
with ManagedFile('data.txt', 'w') as f:
    f.write('hello')

Exception Handling in Context Managers

The real power of context managers lies in exception handling. The __exit__ method receives the exception type, value, and traceback. You can inspect them and either re-raise (by returning False), suppress (by returning True), or transform the exception. Common patterns include logging, cleanup on errors, and converting one exception to another.

For instance, you might want to wrap a low-level IOError into a custom NetworkError. The key pitfall: if you raise a new exception inside __exit__ while an exception is already active, Python 3.7+ sets the new exception's __context__ to the original, allowing chained debugging. But if you raise a new exception when no exception occurred (clean exit), that new exception simply propagates. Test both paths.

class DatabaseConnection:
    def __init__(self, connection_string: str):
        self._conn_string = connection_string
        self._conn = None

    def __enter__(self):
        print(f"Connecting to {self._conn_string}")
        self._conn = ...  # real connection logic
        return self._conn

    def __exit__(self, exc_type, exc_val, exc_tb):
        if exc_type is not None:
            import logging
            logging.warning(f"Database error occurred: {exc_val}")
            raise DatabaseError(f"Dependency failed: {exc_val}") from exc_val
        self._conn.close()
        return False

Using contextlib for Simpler Context Managers

Writing a class with __enter__ and __exit__ is explicit but verbose. Python's contextlib module provides the @contextmanager decorator that turns a generator function into a context manager. The generator yields exactly once — that's the execution point where the with block runs. Setup goes before yield; teardown goes after yield. Exceptions are injected via generator.throw().

This approach reduces boilerplate and makes the resource lifecycle more readable. But beware: the generator must yield exactly once. If it yields twice, a RuntimeError is raised. Also, if the managed block raises an exception that the generator catches but then raises a different exception, the second exception propagates and the first is lost — unless you chain it. Always use try/finally around the yield to guarantee teardown.

from contextlib import contextmanager

@contextmanager
def managed_file(filename: str, mode: str = 'r'):
    file = None
    try:
        file = open(filename, mode)
        yield file
    finally:
        if file:
            file.close()

with managed_file('data.txt', 'w') as f:
    f.write('hello')

Nested Context Managers and Advanced Patterns

Real-world code often needs multiple context managers. You can nest with statements, but that becomes messy when the number grows. Python 3.1 introduced with A as a, B as b:, but for dynamic collections, contextlib.ExitStack is the right tool. ExitStack lets you manage multiple context managers as a stack: you push entries, and they are cleaned up in reverse order (LIFO) when the stack exits.

One less-known trap: if one of multiple comma-separated context managers raises during __enter__, all already-opened managers are still cleaned up. But if you're not using ExitStack, the order of cleanup is reverse of entry. ExitStack makes that explicit.

from contextlib import ExitStack, contextmanager

@contextmanager
def managed_connection(db_name: str):
    print(f"Opening {db_name}")
    yield f"conn_{db_name}"
    print(f"Closing {db_name}")

with ExitStack() as stack:
    conns = [stack.enter_context(managed_connection(f"db{i}")) for i in range(3)]
    print(f"All connections open: {conns}")
# After the with block, each connection is closed in reverse order.

Testing Context Managers for Production Reliability

Context managers are easy to test incorrectly. Most unit tests only cover the happy path: enter, do work, exit. The tricky parts are exception paths and cleanup guarantees. You should inject exceptions at every stage: during __enter__, inside the managed block, and during __exit__. Use pytest fixtures and monkeypatch to simulate failures.

Here's a test pattern that exercises all three failure points. The most insidious test gap is when __exit__ itself raises while an exception is already active. CPython 3.7+ converts that to a new exception with the original in __context__, but many teams miss this because they don't test dual-exception scenarios.

import pytest
from io.thecodeforge.context_manager import ManagedFile

def test_context_manager_exception_during_block():
    with pytest.raises(ValueError):
        with ManagedFile('/tmp/test.txt', 'w') as f:
            raise ValueError("Simulated error")
    # After the block, the file should be closed
    import os
    # Check file descriptor (simplified)
    assert True  # In real test, verify close was called

def test_context_manager_exception_during_exit(monkeypatch):
    def failing_close():
        raise OSError("Close failed")
    with ManagedFile('/tmp/test2.txt', 'w') as f:
        monkeypatch.setattr(f, 'close', failing_close)
    # __exit__ should not suppress the OSError
    # In practice, this will raise OSError when exiting with block
    # This test is for illustration
    pass

Async Context Managers: __aenter__ and __aexit__

Python 3.5 introduced async context managers for use with async with. They follow the same pattern but with coroutines: __aenter__ and __aexit__ are async methods that return awaitable objects. The @contextlib.asynccontextmanager decorator works analogously for async generators.

Async context managers are essential for managing resources in asynchronous code — database connections, aiohttp sessions, file handles in asyncio. The cleanup guarantees are the same as sync managers: __aexit__ is always called, even if the async block raises an exception. A common mistake: forgetting to make __aexit__ a coroutine, which results in a RuntimeError. Another: performing blocking I/O inside __aexit__ without awaiting, which stalls the event loop.

import asyncio
from contextlib import asynccontextmanager

class AsyncDatabaseConnection:
    def __init__(self, dsn: str):
        self._dsn = dsn
        self._conn = None

    async def __aenter__(self):
        self._conn = await connect_to_db(self._dsn)
        return self._conn

    async def __aexit__(self, exc_type, exc_val, exc_tb):
        if self._conn:
            await self._conn.close()
        return False  # propagate exceptions

@asynccontextmanager
async def managed_session(dsn: str):
    conn = await connect_to_db(dsn)
    try:
        yield conn
    finally:
        await conn.close()

async def example():
    async with AsyncDatabaseConnection("postgres://...") as conn:
        await conn.execute("SELECT 1")
    # conn is closed