Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104197
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=x3ojf6LTNgK7+KdtEomboTvXRwrc2Su7eXNmcK8nBYSd1/0TlsPyELRI4zJF8H
	VOchkFdIZoA8WOj2ecJB0BQZhuGkpviLZ6BHUJUpS5NJn0nLABGD7TldHLhc+fXP
	jsoQaQkDYrHi0FDC1bDl+zxVYwCb7hMYDdSB4tVRYo7+0=;
MIME-Version: 1.0
References: <CAF+90c_wZvdgVbmdHH+7J=CLx-rivDRr4vB3=HXK3K2HSNAqMg@mail.gmail.com> <CAF+90c_HaeydyEk2qyM=vxQC-_N6KKwCw_WPo1osP1Nkv99cfw@mail.gmail.com>
In-Reply-To: <CAF+90c_HaeydyEk2qyM=vxQC-_N6KKwCw_WPo1osP1Nkv99cfw@mail.gmail.com>
Date: Tue, 5 Feb 2019 18:55:38 +0200
Message-ID: <CAJHtznyX9P565B9S+3PHmX1m_SY32e_2eb3fjjYmsMRWue3LEA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000077fbcf0581287bb9"
Subject: Re: [PHP-DEV] Re: Don't silence fatal errors
From: zeev@php.net (Zeev Suraski)

--00000000000077fbcf0581287bb9
Content-Type: text/plain; charset="UTF-8"

On Tue, Feb 5, 2019 at 5:17 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
>
>
> I'd like to move forward with this change. I think the overall reception
> here has been positive, although in the discussion some other possibilities
> that avoid/reduce the BC aspect have been discussed. I think now that we
> have a PHP 8 branch, it would make sense to apply this as-is. The BC break
> is quite minor (compared to the other changes in PHP 8) and I think this is
> the cleanest way to solve the problem, as it only changes the list of
> silences errors, without introducing any new error handling concepts or
> mechanisms.


I don't think that other changes that may or may not make it into PHP 8
should influence our decision -  BC breaks accumulate and the more you have
of them, the more difficult it is to migrate.  I'm also present unaware of
anything we already decided to 'break' in PHP 8 as of now (with the
exception of the removal of deprecated 7.x features).

That said - I think we all agree the BC breakage scope is small - but at
the same time, it may be quite fatal for those that are affected.  Those
who have display_errors on (which is both horrible for production and at
the same time fairly popular) are risking exposing sensitive data that
beforehand, they were safely and explicitly hiding using @.

Is there any reason *not* to do it in such a way that provides a gentler
migration path?  Introduce a new error level that would be a part of E_ALL
in 7.4, but outside of E_ALL in 8.0 - that would govern whether fatal
errors are silenced or not.

Zeev

--00000000000077fbcf0581287bb9--