Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128279
Feedback-ID: id5114917:Fastmail
Message-ID: <c28185d9-83e8-453c-9b65-a377d9af2f34@rwec.co.uk>
Date: Mon, 28 Jul 2025 18:56:44 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [DISCUSSION] User-land Throwable
Content-Language: en-GB
To: internals@lists.php.net
References: <CANTuiHvOSimVNPpDxVE5KE8AW63HZmC5=kuSy_uRy_nJRgS9+w@mail.gmail.com>
 <73a35675dff31a1eaf76b67af567194e@bastelstu.be>
 <CAF-mU4xFaRExJdpMAnXTD3rVHnM=k=Kdv5QAh4v7+CJ4V0-e2w@mail.gmail.com>
 <67c55236-268b-47d3-9873-dec4732876b5@app.fastmail.com>
In-Reply-To: <67c55236-268b-47d3-9873-dec4732876b5@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

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]