Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113396
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Thu, 4 Mar 2021 23:26:23 -0500
References: <CAFPFaMLhUtvygtkgWvDRYZvCc8sFNtVDiUEmAHjuXK+H=aFHbA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <CAFPFaMLhUtvygtkgWvDRYZvCc8sFNtVDiUEmAHjuXK+H=aFHbA@mail.gmail.com>
Message-ID: <7D86BD2A-3D54-41A1-8BAE-2E65AB155271@newclarity.net>
Subject: Re: [PHP-DEV] [RFC] Extend error control operator to suppress
 exceptions
From: mike@newclarity.net (Mike Schinkel)



> On Mar 4, 2021, at 9:08 AM, G. P. B. <george.banyard@gmail.com> wrote:
>=20
> Hello internals,
>=20
> 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
}=20
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,=20
2. What catch(union_class_list) would look like in practice,=20
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? =20

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.
>=20
> Best regards,
>=20
> George P. Banyard
>=20
> [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