> On Mar 4, 2021, at 9:08 AM, G. P. B. <george.bany...@gmail.com> wrote:
>
> Hello internals,
>
> This new RFC which I'm proposing is to extend the capability of the error
> control operator @ to not just suppress diagnostic messages but also
> exceptions.
> It can currently be found on GitHub: [1]
> https://github.com/Girgias/error-control-operator-exceptions-rfc
Reading it several times, it is still not clear to me what the following means
from the Proposal section:
-------------------------
Add the following syntax @<union_class_list> to suppress only the exceptions
within the class list, this is similar to:
try
{
expression
}
catch (union_class_list) {}
As such @<\Throwable>expression and @expression are identical.
-------------------------
Specifically:
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?
> The main motivation for this is to provide a path to migrate in a backwards
> compatible manner away from diagnostics such as E_WARNING to the use of
> exceptions without breaking 99% of PHP code which has been written in the
> last 25years.
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?
IOW, are you proposing a requirement to change existing code but in a form that
could be (almost?) completely automated? Is that the how you are envisioning
this aspect of BC to work?
> This proposal on it's own would not be sufficient to trigger such a change
> for extensions but in combination with another proposal to introduce a
> `throw_on_error` declare [2] it could provide a bridge for a gradual
> transition to the use of more exceptions internally.
Would you also consider adding a reciprocal `error_on_exception` declare?
> Although I'm not thrilled with the idea of shoving more functionality into
> @ I don't see any other way, and thus I think it a necessary evil to
> improve the long term health of the PHP project.
What do you see as the downside of shoving more functionality into @? Is the
concern anything more than making the source for PHP more complicated to
maintain?
> Feedback on this RFC and different ideas on how to tackle this topic are
> highly appreciated and welcomed.
>
> Best regards,
>
> George P. Banyard
>
> [1] https://github.com/Girgias/error-control-operator-exceptions-rfc
> [2] Draft RFC for throw_on_error declare
> https://github.com/Girgias/php-rfc-throw-on-error-declare
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
