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
