Re: [RFC] Throwable Hierarchy Policy for Extensions
On Mon, Apr 28, 2025, at 3:30 PM, Tim Düsterhus wrote:
> 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.
I was thinking the same thing. The main one that comes to mind is ArgumentCountError, where while
doing some interesting meta-coding I had to do this:
https://github.com/Crell/AttributeUtils/blob/master/src/Analyzer.php#L123
>> * "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.
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 ExampleException {} and interface
ExampleError {}, instead of class ExampleException extends Exception {}, etc.
--Larry Garfield
Thread (18 messages)