Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127228
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 28 Apr 2025 15:04:02 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <4de85c52-9c04-4e66-9654-af1a377015e1@app.fastmail.com>
In-Reply-To: <8c35314a-e307-4018-8685-39d7a7923cbe@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>
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 Sun, Apr 27, 2025, at 4:45 PM, Tim D=C3=BCsterhus wrote:
> Hi
>
> On 4/27/25 23:16, Kamil Tekiela wrote:
>> The exception message MUST NOT be the only means of distinguishing
>> exceptions. Any two exceptions with different messages MUST be
>> identifiable either by a unique exception class name or code.
>
> Thank you. I have used that as the basis for this change:
>
> https://github.com/php/policies/pull/17/files/7f7bb9bd09f3883bd13a70d7=
f61abbc62bfe04a1..dd507261a61cf088d07d9bdca80d91dcc54daf8a
>
> I've intentionally adjusted the wording to "different cause" rather th=
an=20
> "different message" to avoid defining what constitutes a different mes=
sage.
>
> As an example, when the CSPRNG fails, we might want to emit different=20
> error messages depending on the CSPRNG driver (e.g. /dev/urandom vs th=
e=20
> getrandom() syscalls), but it's not useful to distinguish these cases=20
> with a different code, since the user does not decide which driver is=20
> used and can't do anything useful with that information.
>
> Even distinguishing between "/dev/urandom does not exist" and=20
> "/dev/urandom exists, but is a regular file instead of a character=20
> device" probably is only useful within the message itself, since neith=
er=20
> is really recoverable from within PHP and allocating and documenting=20
> codes is likely work that helps no one.
>
> Best regards
> Tim D=C3=BCsterhus

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.

A few other notes:

* Should the property be specified as public/readonly?  Should it be con=
ventional to have accessor methods?  (IMO, property FTW, no need for a m=
ethod.  I already do this in all my exceptions.)

* "Non-base exceptions MAY define additional properties to provide addit=
ional metadata about the nature of the error."  I am tempted to strength=
en that to SHOULD, to help drive the point home.  Maybe use a SHOULD, an=
d at the end add "unless the nature and details of the error is fully de=
fined by the exceptions' type."

* Would allowing an extension-tagging interface instead of a base class =
be an option?  It still allows for catching "anything thrown by this ext=
ension", which I presume is the goal.  If not, why?

--Larry Garfield