Re: [RFC] Context Managers

On 15 April 2026 15:52:17 BST, Larry Garfield <larry@garfieldtech.com> wrote: >>> 3. 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 paths to the same thing? > >There's a subtle but important difference here: An exception passed through exitContext() >is the original exception from lower in the call stack, and its backtrace will be the original >location of the error. An exception thrown from within exitContext() itself indicates a failure >that the Context Manager is responsible for, usually an error in the exitContext() logic itself. PHP collects traces when exceptions are constructed, not when they're thrown, so this is a distinction without a difference. From the outside, it's impossible to tell the difference between "return $e;" and "throw $e;". That means you have the following options: - 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 logic, which as Rob points out will hide the passed exception unless you remember 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 value be "void", and leave it to the implementation to throw or not. In practice, as you say, "throw unchanged" will be common, but unless that's the behaviour of a *null* return (i.e. the default if not opted out), "throw $e;" seems the natural boilerplate for that. Regards, Rowan Tommins [IMSoP]