Re: [RFC] Context Managers

On Wed, Apr 22, 2026, at 20:28, Larry Garfield wrote: > I think a key question to answer here is: Do we care to differentiate between CM errors and > underlying errors? I don't think we need to differentiate at the CM level. Suppression is a policy decision that belongs to the caller, not the context manager. The CM's job is cleanup: rollback the transaction, close the file, release the lock, etc. Whether the exception continues propagating after that is the caller's call, and try using already provides exactly that: try using ($db->transaction() => $conn) { $conn->execute('INSERT INTO orders ...'); } catch (ValidationException $e) { // Caller chooses to suppress this here } That makes exitContext() simple: return void, do your cleanup, and get out. If cleanup fails, it throws naturally, and the desugared form can chain the original exception as $previous so the root cause isn't lost.. If the caller wants to suppress or differentiate, they already have try using for exactly that. It's worth noting that every example in the RFC (database transactions, file locks, error handler swaps, async scopes) does cleanup and propagates. None of them actually need the power to suppress. If a context manager wants to give callers a clean exception hierarchy to catch against, it can wrap underlying exceptions in their own types during cleanup. That's just normal exception design, no special syntax required. — Rob