Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87319
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
References: <CALYT1Yo-ae+cemXaaXs5Jv5t2DSzdxdYuxuhEGbXyoo_863+bw@mail.gmail.com>
 <836BA21C-AE99-4E7B-AB06-EBC30E41BA0E@icicle.io>
 <CAKws9z2PQWT7rSsM5R9TD-O69Ovy7-eifAuF-S0BQhBh3z4h1w@mail.gmail.com>
 <0AD335F5-35F3-4D98-8F82-800A1EDF8FD8@icicle.io>
 <05f101d0c838$fcdab5e0$f69021a0$@belski.net>
 <CAKws9z0yjxWisObfQ323rk3fA78yqJtRG=6zYDvjuPHEKH4=ag@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Message-ID: <55B63FDF.6050100@gmail.com>
Date: Mon, 27 Jul 2015 15:27:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAKws9z0yjxWisObfQ323rk3fA78yqJtRG=6zYDvjuPHEKH4=ag@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
From: rowan.collins@gmail.com (Rowan Collins)

Scott Arciszewski wrote on 27/07/2015 07:57:
> My only concern is that, we have a fixed timetable for the 7.0.0
> release. It's certainly a good idea to develop a cogent strategy
> before moving forward, but I worry that bikeshedding will get involved
> and we won't make the deadline.
>
> I propose that, if a better strategy cannot be presented in time for
> RC1, consistency should take a back seat to security. Fail hard, throw
> an Error, deal with the details later.

I think taking on board Anatol's concerns about proper planning and 
consistency, and yours about short timescales, the reasonable solution 
is to create as small a possibility for future BC as possible, while 
maintaining the "fail hard" policy.

My suggestion would therefore be to raise an E_ERROR for this case in 
7.0. Unlike an E_RECOVERABLE_ERROR or any kind of Throwable, there is no 
way that code can be written to explicitly handle that case, it will 
simply halt execution. As such, there are no limits to what we can 
introduce later, other than that unmodified code should continue to fail 
hard.

This buys us time to put together a cogent policy for what if any 
built-in functions can make use of Throwables in the 7.x release series, 
with a likely result of throwing some class of Error for this function 
in 7.1.

Regards,
-- 
Rowan Collins
[IMSoP]