Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106718
MIME-Version: 1.0
References: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com>
In-Reply-To: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com>
Date: Wed, 28 Aug 2019 12:27:58 +0100
Message-ID: <CALKiJKobRCksGN85CrLZbh4Fw5VtZFNiwVQkX2MK2nggr-XujA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000066b1f05912baf2d"
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000066b1f05912baf2d
Content-Type: text/plain; charset="UTF-8"

On Wed, 28 Aug 2019 at 10:33, Nikita Popov <nikita.ppv@gmail.com> wrote:

> I think it's time to take a look at our existing warnings & notices in the
> engine, and think about whether their current classification is still
> appropriate. Error conditions like "undefined variable" only generating a
> notice is really quite mind-boggling.
>


While I agree with the reasoning behind this, I think we should be very,
very careful of promoting anything beyond Warning. While it's certainly
true that bugs may be hiding behind Notices and Warnings, it's equally
certain that there is code that is poorly written but has entirely correct
behaviour; for such code, the cure will be worse than the disease, because
an unhandled Error is like suddenly pulling the plug out of the server in
the middle of a transaction.

That's why I was very careful with my undefined constant RFC [1] to first
raise the Notice to a Warning, and leave an appropriate period before
raising to Error. I would be 100% behind raising undefined variable from
Notice to Warning, but think the impact of raising to Error is high enough
that it would risk delaying take-up of PHP 8. Is it too late to raise to
Warning in 7.4, with a clear message that it will be an error in 8.0? That
would give time for people to discover it in rare code paths, get changes
pushed to third-party libraries, etc, before it becomes an unavoidable
error.

[1] https://wiki.php.net/rfc/deprecate-bareword-strings
-- 
Rowan Collins
[IMSoP]

--000000000000066b1f05912baf2d--