Re: [RFC] Context Managers

On Wed, Apr 29, 2026, at 17:04, Larry Garfield wrote: > On Wed, Apr 29, 2026, at 9:30 AM, Rob Landers wrote: > > 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 > > Just to make sure I'm following you, you're arguing that a CM should not have any way > at all to suppress an exception? I don't think I'd agree with that, personally. Even if > it's a rare case, I do believe it's a feature that should remain. I'd argue CMs are mechanisms, not policies. They encode setup and teardown. Suppression is an error-handling policy decision that should be visible at the call site, not mixed with the concerns of setting up and tearing down resources. If CM's could suppress arbitrary exceptions, from a developer stepping over the code, they'd see the code randomly appear to jump out of the using block after a suppressed exception ... at seemingly arbitrary points. There would be no way to trust what you were reading without having the CM's code in front of you as well. — Rob