Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110257
MIME-Version: 1.0
References: <CAD2kNXAEjKW-VQC3PJUzBR9QTL=UEz=OGSTHNvee5tibDECN_Q@mail.gmail.com>
In-Reply-To: <CAD2kNXAEjKW-VQC3PJUzBR9QTL=UEz=OGSTHNvee5tibDECN_Q@mail.gmail.com>
Date: Fri, 22 May 2020 19:22:17 +0200
Message-ID: <CAFPFaMK4CxVEmd92RfmudRO-PXjSLxSBmjYVMTihs=ATaNu_WA@mail.gmail.com>
To: Katie Volz <iggyvolz@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009a7d7a05a63fdfc2"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Error Exceptions mode
From: george.banyard@gmail.com ("G. P. B.")

--0000000000009a7d7a05a63fdfc2
Content-Type: text/plain; charset="UTF-8"

On Fri, 22 May 2020 at 18:09, Katie Volz <iggyvolz@gmail.com> wrote:

> Hello internals,
>
> I want to start a discussion on an RFC to add a declare() statement to
> convert all errors triggered within a file to exceptions.
>
> Currently, the only way to handle notices/warnings in an exception-like
> manner is via set_error_handler, (for example, example #1 on
> https://www.php.net/errorexception) - however this has several
> disadvantages (in particular, it cannot be safely used in libraries without
> affecting other libraries).  The declare() would only affect code on the
> particular PHP file for which the declare was set to 1, in the same way
> that strict_types only affects code on a particular PHP file.  I have
> listed error_exception, error_exceptions, and strict_errors as potential
> names for the declare(), although I don't feel that any of them clearly and
> succinctly describe what is happening here (if anyone has a better name I'm
> certainly interested).
>
> As I do not have wiki karma, I have posted a draft RFC here:
> https://github.com/iggyvolz/php-rfcs/blob/master/error-exceptions.txt.  A
> partially complete patch is linked at the bottom of the draft (very much
> based off the strict_types patch).
>
> Thanks,
> Katie Volz
>

I did a similar PoC last summer (see:
https://github.com/php/php-src/pull/4549)
where Nikita commented that a lot of those warnings could/should be promoted
to error regardless, and this is what myself and a couple of other people
have
been during for the past year.
There are still extensions which didn't receive this treatment mostly due
to lack
of time and hands, so if you want to join on this feel free to send a PR to
php-src

Due to the work already done, I personally see less interest in such a
declare.
Mostly because doing a promotion of these warnings, which are usually tied
in to a failure return value such as null or false, allows us in some
instance to
"clean" up the return value, but only if it's done on the extension
level/in core.

Now I do acknowledge the number of E_WARNINGs still present on master is
large, but I'd personally prefer to focus on making the language better for
everyone and let legit warnings be warnings mostly due to the legacy
behaviour
for I/O operations.

Best regards

George P. Banyard

--0000000000009a7d7a05a63fdfc2--