Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130709
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 29 Apr 2026 10:04:55 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <e84561a6-be65-4561-b256-f67338accc1c@app.fastmail.com>
In-Reply-To: <8ab92f4f-0fce-4239-9732-2d5c7ae1159d@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>
Subject: Re: [PHP-DEV] [RFC] Context Managers
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

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?=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 manager.=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 form=20
> can chain the original exception as `$previous` so the root cause isn'=
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 transactions=
,=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 syntax=20
> required.
>
> =E2=80=94 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 fe=
ature that should remain.

--Larry Garfield