Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113411
Message-ID: <E1D1562B-181C-4B8B-B27D-25116E901E1B@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6DA8E473-E777-488D-B9FE-F5750BDCC0ED"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Sat, 6 Mar 2021 15:40:48 -0500
In-Reply-To: <CAFPFaML+V3ENspXSb=B9cEZw+cRFt9CV+gPVGWQvbWVuY7E69g@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: "G. P. B." <george.banyard@gmail.com>
References: <CAFPFaMLhUtvygtkgWvDRYZvCc8sFNtVDiUEmAHjuXK+H=aFHbA@mail.gmail.com>
 <7D86BD2A-3D54-41A1-8BAE-2E65AB155271@newclarity.net>
 <CAFPFaML+V3ENspXSb=B9cEZw+cRFt9CV+gPVGWQvbWVuY7E69g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Extend error control operator to suppress
 exceptions
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_6DA8E473-E777-488D-B9FE-F5750BDCC0ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Mar 6, 2021, at 10:30 AM, G. P. B. <george.banyard@gmail.com> =
wrote:
>=20
> As Rowan has addressed your first points, I'll skip them but will add =
a code example to clarify in the RFC.
>=20
> On Fri, 5 Mar 2021 at 04:26, Mike Schinkel <mike@newclarity.net =
<mailto:mike@newclarity.net>> wrote:
> > 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.
>=20
> Would you also consider adding a reciprocal `error_on_exception` =
declare?
>=20
> I would not, as diagnostics (I've started to really despise the =
wording
> error/traditional error for E_NOTICE/E_WARNING and co) can always be =
elevated
> back to an exception by using a custom error handler.Now in theory the
> opposite is also true you can set an exception handler and raise an =
E_WARNING,
> but this is mostly a useless operation as you're already at the top of =
the
> execution stack.

Thank you for responding to this. However, throwing a traditional error =
was not was I was suggesting although in hindsight my choice of declare =
name would indicate exactly that. =20

What I was suggesting for have a way to tell all functions that throw =
Exceptions to simply return instead. =20

But after further consideration, for that to be useful I realized that =
such an approach would require more than just a directive and that is =
what I emailed you privately to consider.

> Because of that, any time a diagnostic might be emitted the VM needs =
to
> perform extra checks to see if it wasn't elevated to an exception and =
perform
> some special care handling.As such a declare which would toggle all =
exceptions
> to diagnostics is a very bad idea IMHO.Even if this is just limited to
> functions/methods and not language constructs, emitting a diagnostic =
is usually
> subpar as to analyse an error one must do extra steps (reading =
error_get_last()
> and branching, etc.)It is true that exceptions can be overused/abused,
> but they are IMHO far superior to diagnostics.=20
>=20
> > 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.
>=20
> 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?
>=20
>=20
> Other than the BC break I think there is also the fact that the @ =
operator
> has a "bad" reputation and users went to great lengths to *not* use it =
by
> utilizing various tricks. And starting now to *promote* the usage of =
it again
> could be seen as a net negative by many people, especially as being =
able to
> use it to completely ignore any sort of Throwable error (be it a =
subclass
> of Error which should probably never be caught and ignored, or a =
subclass
> of Exception where it usually would make sense) in such an "easy" =
manner
> could lead to overusing exceptions for dataflow although exceptions
> (at least how my PoC is currently implemented) are still expensive to =
create
> just to be tossed away immediately.

Ah, good points.  Thanks.

Seems like there is a need to be able to say "Don't throw the exception, =
just return it to be so I can handle it immediately" but not require a =
minimum of five lines of try{}catch{} construct, especially if in this =
special case generating the call stack was omitted because it would =
clearly not be needed...?

-Mike=

--Apple-Mail=_6DA8E473-E777-488D-B9FE-F5750BDCC0ED--