Re: [RFC] Throwable Hierarchy Policy for Extensions
On Sun, Apr 27, 2025, at 4:45 PM, Tim Düsterhus 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/7f7bb9bd09f3883bd13a70d7f61abbc62bfe04a1..dd507261a61cf088d07d9bdca80d91dcc54daf8a
>
> I've intentionally adjusted the wording to "different cause" rather than
> "different message" to avoid defining what constitutes a different message.
>
> As an example, when the CSPRNG fails, we might want to emit different
> error messages depending on the CSPRNG driver (e.g. /dev/urandom vs the
> getrandom() syscalls), but it's not useful to distinguish these cases
> with a different code, since the user does not decide which driver is
> used and can't do anything useful with that information.
>
> Even distinguishing between "/dev/urandom does not exist" and
> "/dev/urandom exists, but is a regular file instead of a character
> device" probably is only useful within the message itself, since neither
> is really recoverable from within PHP and allocating and documenting
> codes is likely work that helps no one.
>
> Best regards
> Tim Düsterhus
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 conventional to have accessor
methods? (IMO, property FTW, no need for a method. I already do this in all my exceptions.)
* "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."
* 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?
--Larry Garfield
Thread (19 messages)