Re: Concept: Lightweight error channels

From: Date: Sun, 27 Apr 2025 05:42:24 +0000
Subject: Re: Concept: Lightweight error channels
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
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


Thread (34 messages)

« previous php.internals (#127192) next »