Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130712
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 30 Apr 2026 09:42:24 +0200
To: internals@lists.php.net
Message-ID: <c8cfc3a8-5155-46fd-95b8-e4c07605a3a1@app.fastmail.com>
In-Reply-To: <e84561a6-be65-4561-b256-f67338accc1c@app.fastmail.com>
References: <a087d9fa-112a-4631-9c84-3efae641e0db@app.fastmail.com>
 <4985896b-c80a-4302-912e-9f572a260fb5@app.fastmail.com>
 <cf6ac562-7e6f-4eca-a514-6aa3c9692461@app.fastmail.com>
 <a748c98a-180a-475f-93a7-b802c21138e2@app.fastmail.com>
 <88716CA9-38E4-45CA-9471-2D8928CF4DE2@rwec.co.uk>
 <3b2b863d-d179-40c9-ad26-8605e854a331@app.fastmail.com>
 <8ab92f4f-0fce-4239-9732-2d5c7ae1159d@app.fastmail.com>
 <e84561a6-be65-4561-b256-f67338accc1c@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Context Managers
Content-Type: multipart/alternative;
 boundary=c458bdc5b03265d2ee63b71cd57ff15d211ffa78
From: rob@bottled.codes ("Rob Landers")

--c458bdc5b03265d2ee63b71cd57ff15d211ffa78
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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 differentia=
te between CM errors and underlying errors?=20
> >
> > I don't think we need to differentiate at the CM level. Suppression =
is=20
> > a policy decision that belongs to the caller, not the context manage=
r.=20
> > The CM's job is cleanup: rollback the transaction, close the file,=20
> > release the lock, etc. Whether the exception continues propagating=20
> > after that is the caller's call, and `try using` already provides=20
> > exactly that:
> >
> > try using ($db->transaction() =3D> $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=20
> > get out. If cleanup fails, it throws naturally, and the desugared fo=
rm=20
> > can chain the original exception as `$previous` so the root cause is=
n't=20
> > lost. If the caller wants to suppress or differentiate, they already=20
> > have `try using` for exactly that.
> >
> > It's worth noting that every example in the RFC (database transactio=
ns,=20
> > file locks, error handler swaps, async scopes) does cleanup and=20
> > propagates. None of them actually need the power to suppress. If a=20
> > context manager wants to give callers a clean exception hierarchy to=20
> > catch against, it can wrap underlying exceptions in their own types=20
> > during cleanup. That's just normal exception design, no special synt=
ax=20
> > required.
> >
> > =E2=80=94 Rob
>=20
> Just to make sure I'm following you, you're arguing that a CM should n=
ot have any way at all to suppress an exception?  I don't think I'd agre=
e 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 teardo=
wn. Suppression is an error-handling policy decision that should be visi=
ble at the call site, not mixed with the concerns of setting up and tear=
ing down resources.

If CM's could suppress arbitrary exceptions, from a developer stepping o=
ver the code, they'd see the code randomly appear to jump out of the usi=
ng 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.

=E2=80=94 Rob
--c458bdc5b03265d2ee63b71cd57ff15d211ffa78
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Wed, Apr =
29, 2026, at 17:04, Larry Garfield wrote:</div><blockquote type=3D"cite"=
 id=3D"qt" style=3D""><div>On Wed, Apr 29, 2026, at 9:30 AM, Rob Landers=
 wrote:</div><div>&gt; On Wed, Apr 22, 2026, at 20:28, Larry Garfield wr=
ote:</div><div>&gt;&gt; I think a key question to answer here is: Do we =
care to differentiate between CM errors and underlying errors?&nbsp;</di=
v><div>&gt;</div><div>&gt; I don't think we need to differentiate at the=
 CM level. Suppression is&nbsp;</div><div>&gt; a policy decision that be=
longs to the caller, not the context manager.&nbsp;</div><div>&gt; The C=
M's job is cleanup: rollback the transaction, close the file,&nbsp;</div=
><div>&gt; release the lock, etc. Whether the exception continues propag=
ating&nbsp;</div><div>&gt; after that is the caller's call, and `try usi=
ng` already provides&nbsp;</div><div>&gt; exactly that:</div><div>&gt;</=
div><div>&gt; try using ($db-&gt;transaction() =3D&gt; $conn) {</div><di=
v>&gt;&nbsp;&nbsp;&nbsp;&nbsp; $conn-&gt;execute('INSERT INTO orders ...=
');</div><div>&gt; } catch (ValidationException $e) {</div><div>&gt;&nbs=
p;&nbsp;&nbsp;&nbsp; // Caller chooses to suppress this here</div><div>&=
gt; }</div><div>&gt;</div><div>&gt; That makes `exitContext()` simple: r=
eturn void, do your cleanup, and&nbsp;</div><div>&gt; get out. If cleanu=
p fails, it throws naturally, and the desugared form&nbsp;</div><div>&gt=
; can chain the original exception as `$previous` so the root cause isn'=
t&nbsp;</div><div>&gt; lost. If the caller wants to suppress or differen=
tiate, they already&nbsp;</div><div>&gt; have `try using` for exactly th=
at.</div><div>&gt;</div><div>&gt; It's worth noting that every example i=
n the RFC (database transactions,&nbsp;</div><div>&gt; file locks, error=
 handler swaps, async scopes) does cleanup and&nbsp;</div><div>&gt; prop=
agates. None of them actually need the power to suppress. If a&nbsp;</di=
v><div>&gt; context manager wants to give callers a clean exception hier=
archy to&nbsp;</div><div>&gt; catch against, it can wrap underlying exce=
ptions in their own types&nbsp;</div><div>&gt; during cleanup. That's ju=
st normal exception design, no special syntax&nbsp;</div><div>&gt; requi=
red.</div><div>&gt;</div><div>&gt; =E2=80=94 Rob</div><div><br></div><di=
v>Just to make sure I'm following you, you're arguing that a CM should n=
ot have any way at all to suppress an exception?&nbsp; I don't think I'd=
 agree with that, personally.&nbsp; Even if it's a rare case, I do belie=
ve it's a feature that should remain.</div></blockquote><div><br></div><=
div>I'd argue CMs are mechanisms, not policies. They encode setup and te=
ardown. 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.</div><div><br></div><div>If CM's could suppress =
arbitrary exceptions, from a developer stepping over the code, they'd se=
e the code randomly appear to jump out of the using block after a suppre=
ssed 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.</div><div><br></div><div>=E2=80=94 Rob</div></body></html>
--c458bdc5b03265d2ee63b71cd57ff15d211ffa78--