Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127231
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 28 Apr 2025 16:09:00 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <bf44d346-0429-4f5b-9b10-dcd9b8aaca00@app.fastmail.com>
In-Reply-To: <a918f1d5-7c37-4851-bf11-8dc112f40e05@bastelstu.be>
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>
 <a918f1d5-7c37-4851-bf11-8dc112f40e05@bastelstu.be>
Subject: Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Apr 28, 2025, at 3:30 PM, Tim D=C3=BCsterhus wrote:
> Hi
>
> On 4/28/25 22:04, Larry Garfield wrote:
>> Holy cow, thank you for this bit.  The inability to tell what went wr=
ong 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=20
> improve this for existing extensions without creating an entirely new=20
> hierarchy and without an RFC.

I was thinking the same thing.  The main one that comes to mind is Argum=
entCountError, where while doing some interesting meta-coding I had to d=
o this:

https://github.com/Crell/AttributeUtils/blob/master/src/Analyzer.php#L123

>> * "Non-base exceptions MAY define additional properties to provide ad=
ditional metadata about the nature of the error."  I am tempted to stren=
gthen 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 =E2=
=80=9Cjust=20
> in case=E2=80=9D they might be useful by using a SHOULD phrasing. I al=
so expect=20
> this to be something that can be resolved by simple agreement during t=
he=20
> RFC discussion or review of the implementation.
>
> I historically also had almost no cases where additional properties on=20
> an exception provided value for *programmatic consumption*. Most of th=
e=20
> cases could be decided by class name alone and the message was=20
> sufficient to provide additional details for the human reader in the=20
> application logs (e.g. the exact nature of a DNS resolution error). Ke=
ep=20
> in mind that additional properties cannot be handled in a generic=20
> fashion, so they are useful for programmatic consumption when catching=
 a=20
> specific exception class only.
>
>> * Would allowing an extension-tagging interface instead of a base cla=
ss be an option?  It still allows for catching "anything thrown by this =
extension", which I presume is the goal.  If not, why?
>
> See the =E2=80=9CChoice of Base Exception=E2=80=9D section in=20
> https://github.com/php/php-src/pull/9220.

That seems to be about not having a common interface for both the Error =
and the Exception, which makes sense.  I'm talking about `interface Exam=
pleException {}` and `interface ExampleError {}`, instead of `class Exam=
pleException extends Exception {}`, etc.

--Larry Garfield