Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130680
Feedback-ID: id5114917:Fastmail
Date: Tue, 21 Apr 2026 13:16:22 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Context Managers
User-Agent: K-9 Mail for Android
In-Reply-To: <a748c98a-180a-475f-93a7-b802c21138e2@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>
Message-ID: <88716CA9-38E4-45CA-9471-2D8928CF4DE2@rwec.co.uk>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 15 April 2026 15:52:17 BST, Larry Garfield <larry@garfieldtech=2Ecom> wr=
ote:
>>>  3=2E I will say it is weird to have exitContext return an exception; =
but what happens if an exception is thrown during exitContext? Why not just=
 have it return void and throw if you need to throw instead of having two p=
aths to the same thing?
>
>There's a subtle but important difference here: An exception passed throu=
gh exitContext() is the original exception from lower in the call stack, an=
d its backtrace will be the original location of the error=2E  An exception=
 thrown from within exitContext() itself indicates a failure that the Conte=
xt Manager is responsible for, usually an error in the exitContext() logic =
itself=2E


PHP collects traces when exceptions are constructed, not when they're thro=
wn, so this is a distinction without a difference=2E From the outside, it's=
 impossible to tell the difference between "return $e;" and "throw $e;"=2E

That means you have the following options:=20

- throw the passed exception unchanged
- return the passed exception, which is equivalent to throwing it
- throw a new exception, or fail to catch an exception in the cleanup logi=
c, which as Rob points out will hide the passed exception unless you rememb=
er to attach it as $previous
- return a new exception, which according to the current RFC text will be =
completely ignored (is "throw $e" supposed to say "throw $__ret"?)


It does seem like it would be more straightforward to have the return valu=
e be "void", and leave it to the implementation to throw or not=2E

In practice, as you say, "throw unchanged" will be common, but unless that=
's the behaviour of a *null* return (i=2Ee=2E the default if not opted out)=
, "throw $e;" seems the natural boilerplate for that=2E=20


Regards,

Rowan Tommins
[IMSoP]