Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87838
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKws9z2V3rYFuPdxLcTcV_9sLEySydcapMOtq3Xu21hmGH-44Q@mail.gmail.com>
References: <CAKws9z25cW7MTFeSanYVJK64Lb1uJYm5JJ82h7DDG1Td+j3EuA@mail.gmail.com>
	<CAPwsocHaTtGjL8CAdzAvbSN2wZSGZ50SRC6MBNKO0WtXzAZu3g@mail.gmail.com>
	<CANUQDCgiJVackjoxDaPmZWn_wCcDAZ=BwvhDzdaXsLhSPFVeRA@mail.gmail.com>
	<99CE9AAF-E6E9-4D37-B462-E4A63139EAFB@icicle.io>
	<CAKws9z0Q2WMxAGVZAgz=noJbViqmEJb43SWo_fB6MTum3ptFDA@mail.gmail.com>
	<CAKws9z2pKRHR0kaTgw=UhLLeUDPS8MpY70PCMsSwsFxJnPbAZw@mail.gmail.com>
	<CANUQDCj-yBLNWGP60YBfjRjtAUMC2SpbQJaVjy3qjhhz0gFAEw@mail.gmail.com>
	<CAHXmDMCW0hP+-hB9Geo-niu+LkvTPKXKrbKkaki=nMuQSRMCuw@mail.gmail.com>
	<CAKws9z2w31Tjya9ctsfQYk416Yb_SRRGRNyCCSsJLRyZ_aHpbQ@mail.gmail.com>
	<CAEZPtU6yRQrGmG-Pw+z28QD+8vKGhvSSQ9vr4mrqE_qCrKubhA@mail.gmail.com>
	<CAKws9z2V3rYFuPdxLcTcV_9sLEySydcapMOtq3Xu21hmGH-44Q@mail.gmail.com>
Date: Fri, 21 Aug 2015 09:36:57 -0400
Message-ID: <CAAyV7nHpV_KujJbS8E+jU3aOTGL9pDDfcwFe=0t-_3A2k+ONnA@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
Cc: Pierre Joye <pierre.php@gmail.com>, Trevor Suarez <rican7@gmail.com>, 
	Niklas Keller <me@kelunik.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
From: ircmaxell@gmail.com (Anthony Ferrara)

On Fri, Aug 21, 2015 at 6:14 AM, Scott Arciszewski <scott@paragonie.com> wrote:
> On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye <pierre.php@gmail.com> wrote:
>> On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski <scott@paragonie.com> wrote:
>>> On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez <rican7@gmail.com> wrote:
>>>> Ah, I didn't realize this thread existed. I had just commented on the old
>>>> one, but the point still stands:
>>>>
>>>> PHP 7.0 RC1 was just tagged.
>>>> Shouldn't this be a relatively high priority to fix/decide so we don't end
>>>> up with behavior that can't be fixed until PHP 8.0?
>>>>
>>>> On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller <me@kelunik.com> wrote:
>>>>>
>>>>> >
>>>>> > Okay, great, we have people on both sides on this discussion. I hope
>>>>> > nobody minds if I sit this part out.
>>>>> >
>>>>> > What specifics need to be discussed? Should somebody set up a poll? (I
>>>>> > don't know how to do that.)
>>>>>
>>>>>
>>>>> You can find information on how to setup a poll in step 6 here:
>>>>> https://wiki.php.net/rfc/howto
>>>>>
>>>>> Regards, Niklas
>>>
>>> I agree that this should be a relatively high priority. I'm not sure
>>> what the next steps would be. (Aside: I still have a PR I need to
>>> write that I've been holding off on until the fate of PHP 7's CSPRNG
>>> feature is determined.)
>>>
>>> Can we reach some sort of consensus on throw new Exception vs throw new Error?
>>
>> I think the best would be a RFC, not only for the decision itself but
>> also to have a clear view about what will be changed or affected.
>>
>> Cheers,
>> --
>> Pierre
>>
>> @pierrejoye | http://www.libgd.org
>
> Fine, let's do this:
>
> 1. Violate the feature freeze for this exceptional decision.
> 2. One of the folks in the camp that WANTS an RFC and a drawn out
> formal decision-making process opens it with a poll.
> 3. Give me voting karma.
>
> Let's NOT make the CSPRNG feature fail open. That is an absolutely
> terrible idea.

My proposal/stance:

Let's make random_* throw an Exception if it cannot connect to a
random source. And let's have it throw an TypeError if ZPP fails, or
Error if min >= max.

The first two are consistent with existing exceptions.

The third (Error if min>max) is where the contention lies. I'm
suggesting Error as it's consistent with parameter errors in the sense
that the type may be correct, but the value isn't (hence it's the same
kind of error as a parameter error, just a different
sub-classification.

MHO is this is too important of a distinction to simply gloss over.
Having it return false (or null) will be a problem, as nobody will
perform the error checks. And returning $x where `$x == 0` in a
security context could be incredibly bad. As such, I think the
security implications here outweigh nearly all of the other concerns
about consistency and convention.

That's my opinion. I'll be happy to make the changes if a RM gives me
the green light to do so.

Thanks

Anthony