Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127229
Message-ID: <a918f1d5-7c37-4851-bf11-8dc112f40e05@bastelstu.be>
Date: Mon, 28 Apr 2025 22:30:11 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
References: <ffadb6e6-5d16-4b45-a020-4b91565e2ee6@bastelstu.be>
 <CAGBsUrc_wjofCOEuz7MNhuVtpmJJwsatDPCjfAdHH6PQriqgZw@mail.gmail.com>
 <c2369d3c-515e-4b8f-a656-bd1265e9d59e@bastelstu.be>
 <CAGBsUrchWDhYX05ztPLGJx0KzyjspeKhu=K=18OVcZLGvTKB0A@mail.gmail.com>
 <8c35314a-e307-4018-8685-39d7a7923cbe@bastelstu.be>
 <4de85c52-9c04-4e66-9654-af1a377015e1@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <4de85c52-9c04-4e66-9654-af1a377015e1@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 4/28/25 22:04, Larry Garfield wrote:
> Holy cow, thank you for this bit.  The inability to tell what went wrong programmatically without string parsing the exception message is one of my biggest pet peeves in current exceptions.

Anything particular from the standard library? It might be possible to 
improve this for existing extensions without creating an entirely new 
hierarchy and without an RFC.

> * Should the property be specified as public/readonly?  Should it be conventional to have accessor methods?  (IMO, property FTW, no need for a method.  I already do this in all my exceptions.)

I would not specify this and let authors make a choice here to determine 
what is appropriate. The URI RFC has `public readonly array $errors;` 
and I think that is appropriate in that case, but in other situations, a 
method might be more appropriate.

> * "Non-base exceptions MAY define additional properties to provide additional metadata about the nature of the error."  I am tempted to strengthen that to SHOULD, to help drive the point home.  Maybe use a SHOULD, and at the end add "unless the nature and details of the error is fully defined by the exceptions' type."

I would not want to encourage authors to add additional properties “just 
in case” they might be useful by using a SHOULD phrasing. I also expect 
this to be something that can be resolved by simple agreement during the 
RFC discussion or review of the implementation.

I historically also had almost no cases where additional properties on 
an exception provided value for *programmatic consumption*. Most of the 
cases could be decided by class name alone and the message was 
sufficient to provide additional details for the human reader in the 
application logs (e.g. the exact nature of a DNS resolution error). Keep 
in mind that additional properties cannot be handled in a generic 
fashion, so they are useful for programmatic consumption when catching a 
specific exception class only.

> * Would allowing an extension-tagging interface instead of a base class be an option?  It still allows for catching "anything thrown by this extension", which I presume is the goal.  If not, why?

See the “Choice of Base Exception” section in 
https://github.com/php/php-src/pull/9220.

Best regards
Tim Düsterhus