Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127233
Message-ID: <39af290b-358a-45f4-9d2d-c76dd4e08125@bastelstu.be>
Date: Mon, 28 Apr 2025 23:27:44 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
References: <ffadb6e6-5d16-4b45-a020-4b91565e2ee6@bastelstu.be>
 <CAGBsUrc_wjofCOEuz7MNhuVtpmJJwsatDPCjfAdHH6PQriqgZw@mail.gmail.com>
 <c2369d3c-515e-4b8f-a656-bd1265e9d59e@bastelstu.be>
 <CAGBsUrchWDhYX05ztPLGJx0KzyjspeKhu=K=18OVcZLGvTKB0A@mail.gmail.com>
 <8c35314a-e307-4018-8685-39d7a7923cbe@bastelstu.be>
 <4de85c52-9c04-4e66-9654-af1a377015e1@app.fastmail.com>
 <a918f1d5-7c37-4851-bf11-8dc112f40e05@bastelstu.be>
 <bf44d346-0429-4f5b-9b10-dcd9b8aaca00@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <bf44d346-0429-4f5b-9b10-dcd9b8aaca00@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 4/28/25 23:09, Larry Garfield wrote:
>>> * 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.

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.