Re: [RFC] Throwable Hierarchy Policy for Extensions
| From: | Tim Düsterhus | Date: | Mon, 28 Apr 2025 21:27:44 +0000 |
| Subject: | Re: [RFC] Throwable Hierarchy Policy for Extensions | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-127233@lists.php.net to get a copy of this message | ||
Hi
On 4/28/25 23:09, Larry Garfield wrote:
Besides not following the de facto standard (which is what this proposal is trying to codify), I'm also not sure what benefit an interface would have over a base exception for the problem we're trying to solve here? So I can return the “why (interface)?”. It would just make it tempting to extend some SPL exception :-) I see the value of using interfaces for exceptions when the functionality implements an interface that defines specific types of exception (e.g. PSR-18), but this is (literally) orthogonal to base exceptions that group exceptions by “library” [1]. Best regards Tim Düsterhus [1] Writing down these words, it would probably made sense for ext/random to define a Random\EngineFailureExceptionInterface and specifying that Random\Engine::generate() must throw that one, rather than directly throwing the Random\RandomException base exception - especially for userland engines. But on the other hand an engine failure is not really programmatically recoverable anyways, so that's probably why I used the "simplification" back when I designed the hierarchy.That seems to be about not having a common interface for both the Error and the Exception, which makes sense. I'm talking about* 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.interface ExampleException {}andinterface ExampleError {}, instead ofclass ExampleException extends Exception {}, etc.