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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
