Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87320
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain paragonie.com from 209.85.220.173 cause and error)
MIME-Version: 1.0
In-Reply-To: <55B63FDF.6050100@gmail.com>
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>
	<55B63FDF.6050100@gmail.com>
Date: Mon, 27 Jul 2015 10:45:08 -0400
Message-ID: <CAKws9z1nXmci53v+3xOnROo-t45hwc9QTzJgdACBgDoi1O7DnQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
From: scott@paragonie.com (Scott Arciszewski)

On Mon, Jul 27, 2015 at 10:27 AM, Rowan Collins <rowan.collins@gmail.com> wrote:
> 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]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

The problem with fatal errors is that "This function can fail
irrecoverably outside of your control" isn't going to encourage
adoption.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises