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

Reply via email to