Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113407
MIME-Version: 1.0
References: <CAFPFaMLhUtvygtkgWvDRYZvCc8sFNtVDiUEmAHjuXK+H=aFHbA@mail.gmail.com>
 <7D86BD2A-3D54-41A1-8BAE-2E65AB155271@newclarity.net>
In-Reply-To: <7D86BD2A-3D54-41A1-8BAE-2E65AB155271@newclarity.net>
Date: Sat, 6 Mar 2021 15:30:20 +0000
Message-ID: <CAFPFaML+V3ENspXSb=B9cEZw+cRFt9CV+gPVGWQvbWVuY7E69g@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000095fa7505bcdfe18f"
Subject: Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions
From: george.banyard@gmail.com ("G. P. B.")

--00000000000095fa7505bcdfe18f
Content-Type: text/plain; charset="UTF-8"

As Rowan has addressed your first points, I'll skip them but will add a
code example to clarify in the RFC.

On Fri, 5 Mar 2021 at 04:26, Mike Schinkel <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.
>
> Would you also consider adding a reciprocal `error_on_exception` declare?
>

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.

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.

> 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?
>
>
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.

Best regards,

George P. Banyard

--00000000000095fa7505bcdfe18f--