Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127199
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 27 Apr 2025 17:51:06 +0300
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Concept: Lightweight error channels
In-Reply-To: <2a2fef34-d610-4f6a-9c7d-16c98c724c83@app.fastmail.com>
References: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com>
 <003901dbb6ee$15dc1c60$41945520$@glaive.pro>
 <2a2fef34-d610-4f6a-9c7d-16c98c724c83@app.fastmail.com>
User-Agent: Roundcube Webmail/1.4.8
Message-ID: <bca4bae4d7516c8c2a92aa959e6f89bf@glaive.pro>
Organization: SIA "Glaive.pro"
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
From: juris@glaive.pro (Juris Evertovskis)

On 2025-04-27 08:42, Larry Garfield wrote:
> There's two key problems with exceptions as PHP currently has them:
> 
> 1. Creating and attaching the backtrace to them is stupidly expensive.
> It's one of the most expensive things you can ask the engine to do, I
> think.

Would an EmptyBacktraceException solve it then? Ideally a LightException 
would gather the call stack in it's backtrace as it bubbles up until 
it's caught. It migth solve most of the legit reporting needs with an 
insignificant performance impact. No idea if it's doable though.

> 2. They're unchecked, which means as a developer calling a function you
> have absolutely no idea what exceptions it might throw without reading
> every line of that function and every function it calls, transitively.
> That means it's extremely easy for an exception to kill the process if 
> no
> one expects to catch it.

Why wouldn't these raises end up with the same issue? I call 
`inverse($x)` of a lib, it calls `div(1, $x)` internally, fails to 
handle the raise and I end up with a crash/exception of the old kind.

Or is `inverse` forced to check every possible raise of `div`? But 
that's probably clumsy, sometimes redundant and not something that can 
be enforced during compilation. So we still end up with runtime 
exceptions from somewhere deep in the lib, but instead of "ZeroDivisor" 
they are "unhandled raise" exceptions?

Sorry, I guess this somewhat overlaps with the bubbling portion that you 
haven't thought through, but I'm continuing to ask because it seems I'm 
not the only one having hard time to grasp the feeling of the proposed 
model.

BR,
Juris