On 28/07/2025 16:27, Larry Garfield wrote:
(I actually have no idea what the original reason was for making so much of
Exceptions final.)
If you start with everything marked "final", you can relax it as needed.
For internal classes particularly, there can be implementation and
performance penalties to letting users over-ride certain parts.
In this case, the trace is actually stored in a private property, and
accessed separately by:
* getTrace()
* getTraceAsString()
* the default output for uncaught errors
* a couple of extensions that do weird hacks with it
Presumably, we would want all of these to polymorphically call
getTrace() instead, to get the customised output. That might not be
trivial, e.g. it means an error handler calling into userland code which
could itself trigger errors.
If we don't provide that consistency, there's not much advantage over
writing $trace = ($e instanceof ThrowableWithCustomisedTrace) ?
$e->getCustomisedTrace() : $e->getTrace();
I wonder if there's actually an X/Y Problem here: is what is actually
wanted more ways to affect what goes into the backtrace, or permanently
edit it? We have #[SensitiveParameter], could we also have
#[SkipCallInTrace]? Could we have a way to construct an exception with a
custom trace?
As long as the format is correct when written to the private property,
we don't need to change existing code that reads directly from that
property.
--
Rowan Tommins
[IMSoP]
