Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113406
To: internals@lists.php.net
References: <CAFPFaMLhUtvygtkgWvDRYZvCc8sFNtVDiUEmAHjuXK+H=aFHbA@mail.gmail.com>
 <7D86BD2A-3D54-41A1-8BAE-2E65AB155271@newclarity.net>
Message-ID: <bdf18b4b-fb8d-e7c4-3a53-9a1be3122d70@gmail.com>
Date: Sat, 6 Mar 2021 13:56:58 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <7D86BD2A-3D54-41A1-8BAE-2E65AB155271@newclarity.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Extend error control operator to suppress
 exceptions
From: rowan.collins@gmail.com (Rowan Tommins)

On 05/03/2021 04:26, Mike Schinkel wrote:
> 1. What @<union_class_list> means and what it would look like in practice,
> 2. What catch(union_class_list) would look like in practice,
> 3. What @<\Throwable>expression means and what it would look like in practice, and
> 4. Can you provide a few concrete code examples, please?


I think I can help out here. "union_class_list" is just referring to the 
fact that a catch clause can (as of PHP 7.1) list multiple exception 
classes in it, using the same syntax as union types: 
"catch(FooException|BarException $e)".

So an example would look like this:

$foo = 
@<FileNotFoundException|InsufficientPermissionException>fopen($bar, 'r');

Which translates to:

try
{
     $foo = fopen($bar, 'r');
}
catch (FileNotFoundException|InsufficientPermissionException)
{
     $foo = null;
}


> I am not clear what you mean by "providing a path to migrate in a BC manner" here.  Would this require developers to prefix all functions calls with @ for functions changed in a future version of PHP to throw exceptions instead of returning values, assuming they do not have the green light from their stakeholders to make more substantive changes to their code?


Rather than "having the green light from their stakeholders", I'd focus 
on the more straight-forward "want upgrading to be as easy as possible".

The two advantages that I see in using @ specifically for this are:

1. It is valid syntax in existing versions of PHP, so code using it can 
be compatible with multiple versions.
2. A lot of people already use it with functions like fopen() to 
suppress the expected warning, so would have to make no change at all.


The problem is that not everybody does prefix, say, fopen() with an @. 
Some people just live with the noise in their logs of the occasional 
Warning; others use an alternative mechanism to suppress it, such as 
wikimedia/at-ease [https://packagist.org/packages/wikimedia/at-ease]

That means a lot of people would still need to change their code if 
fopen() started throwing exceptions, weakening advantage #2.


If you make people opt into exceptions, e.g. using 
declare(throw_on_error=1) then you actually lose *both* advantages:

1. Every file you add the new declare() line to will no longer run on 
older versions of PHP.
2. Since you're changing every file anyway, in a non-compatible way, you 
can do some find-and-replace at the same time. For instance, changing 
"if(@fopen($filename))" into "if(try(fopen($filename)))".

I'm also not convinced a file-level opt-in is a sensible long-term 
strategy. The risk of writing code assuming one error style in a file 
actually set to the other seems too high.


The more I think about it, the more I get the feeling that while this 
proposal has some great ideas, it hasn't got the combination quite right 
yet.


Regards,

-- 
Rowan Tommins
[IMSoP]