Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87880
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.28 cause and error)
Message-ID: <55D9F2AB.8040404@garfieldtech.com>
Date: Sun, 23 Aug 2015 11:19:55 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <20150823003346.A6E6B2617DA@dd15934.kasserver.com>
In-Reply-To: <20150823003346.A6E6B2617DA@dd15934.kasserver.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [Discuss] Random Functions Throwing Exceptions
 in PHP 7.0.0
From: larry@garfieldtech.com (Larry Garfield)

On 08/22/2015 07:33 PM, Thomas Bley wrote:
> Anthony Ferrara wrote on 22.08.2015 21:58:
>
>> All,
>>
>> I am putting a simple RFC up for discussion to make random_* throw
>> exceptions on failure in order to ensure we fail-closed.
>>
>> https://wiki.php.net/rfc/random-function-exceptions
>>
>> Considering this topic has already been discussed, I intend to open
>> voting on this as soon as allowable. Given the voting policy specifies
>> 2 weeks for language changes and 1 week for another, this is assumed
>> to require 1 week of "discussion".
>>
>> With that in mind, I intend to put this RFC up to vote on August 29/30th.
>>
>> Thanks!
>>
>> Anthony
>>
>> -- 
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>

*snip*

> If people use this function without reading documentation, they will also use other things without documentation like database queries without binding/escaping, inject html without escaping, etc.
> Having core functions suddenly throw exceptions causes many problems in the code structure.
>
> Regards
> Thomas

It's actually the other way around that is the compelling argument here.

We *already know* that developers use things without documentation, like 
database queries without binding/escaping, inject HTML without escaping, 
etc.  These things happen all the time, despite extensive documentation 
efforts to prevent them from doing so.  Therefore, there is little 
evidence to suggest that documenting "you must check the return value to 
make sure it's not false", no matter how big, red, and flashing we made 
it, will result in people actually doing so.

If we want these functions to be safely used, they need to be naively 
safe to use.  They simply won't be used safely otherwise, and these are 
high-sensitivity functions (by design).

--Larry Garfield