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
