Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127192
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 27 Apr 2025 00:42:24 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <2a2fef34-d610-4f6a-9c7d-16c98c724c83@app.fastmail.com>
In-Reply-To: <003901dbb6ee$15dc1c60$41945520$@glaive.pro>
References: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com>
 <003901dbb6ee$15dc1c60$41945520$@glaive.pro>
Subject: Re: [PHP-DEV] Concept: Lightweight error channels
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Apr 26, 2025, at 3:59 PM, Juris Evertovskis wrote:
> Hi,
>
> Reading this as a PHP dev is confusing (terminology-wise) because errors
> used to be the fatal ("stop the world") conditions while exceptions were the
> catchable, recovarable issues within some call - feels to me pretty
> equivalent to what you're proposing here.
>
> What's the problem with PHP exceptions? I'm not even trying to argue, I'm
> trying to understand. Is it the implementation (bad/expensive performance)?
> Semantics? Handling syntax?

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.
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.

What I am proposing is something that works somewhat like exceptions, but without either of those problems, to handle cases where the immediate caller is the obvious responsible party to handle the error case.  "Heavy" exceptions will continue to be useful for "the database caught fire" type errors, where crashing the whole system is reasonable and it's just a question of how to do so gracefully.

> I didn't understand the bubbling changes either. What do you mean by
> "fatal"? Does it turn the raised "light error" into a real exception? Or
> does it turn into an actual error crashing the whole process?

The details here are one of the things I haven't thought through yet (hence the point of the email, which is asking "is it worth my time to think through these things?")  Most likely, an unhandled raise or an invalid raise would get converted to a thrown Error of some kind, which would be handleable like any other Error (which is generally "log and then crash").  That situation would be a "the developer screwed up" bug 100% of the time, so a thrown Error is the correct response.

--Larry Garfield