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