Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87663
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.179 as permitted sender)
MIME-Version: 1.0
References: <CAKws9z25cW7MTFeSanYVJK64Lb1uJYm5JJ82h7DDG1Td+j3EuA@mail.gmail.com>
In-Reply-To: <CAKws9z25cW7MTFeSanYVJK64Lb1uJYm5JJ82h7DDG1Td+j3EuA@mail.gmail.com>
Date: Thu, 06 Aug 2015 07:58:54 +0000
Message-ID: <CAPwsocHaTtGjL8CAdzAvbSN2wZSGZ50SRC6MBNKO0WtXzAZu3g@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113eceb2a30453051c9fe4b3
Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
From: leight@gmail.com (Leigh)

--001a113eceb2a30453051c9fe4b3
Content-Type: text/plain; charset=UTF-8

On Thu, 6 Aug 2015 00:55 Scott Arciszewski <scott@paragonie.com> wrote:

All,

I'd like to move the conversation towards a decision regarding PRs
1397 and 1398. These decisions are blocking random_compat as well as a
security enhancement to random_bytes (merge conflicts are *the
worst*).

Here's a quick recap

Arguments:

1. Consistency is more important than security.

> random_* should be consistent with the rest of PHP (sans intdiv()).
> They should return false and emit an E_WARNING
> or E_ERROR warning (the latter is if we want it to fail closed).
>
> It's the responsibility of the developer to know this can
> happen and explicitly check for it. Don't throw anything.

2. Security is more important than consistency.

> Placing more responsibility on the developer increases the
> likelihood of an implementation error. We should aim for compatible
> usability with rand() and mt_rand() for random_int(), which never return
> false. For random_int() and random_bytes(), should PHP be unable
> to generate a random value (no random device available, file
> descriptor exhaustion, etc.) an exception should be thrown. If the
> developer wants to handle it gracefully, they can place it in try/catch
> blocks (which raising errors make messy). Otherwise, the default
> state is to fail closed (i.e. terminate script execution).

Open Questions:

1. Under what conditions should an Exception be thrown, and which
should throw an Error instead?

Did I miss any?

I'm in favor of throwing *something*. As for the particulars of what
should be an Exception and what should be an Error, I don't have a
horse in this race. Exceptions already existed and Errors were already
accepted in the Throwable RFC, so I don't believe this warrants
another RFC and putting this decision off until 7.1.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


We also -need- a consensus in place because we have more security sensitive
features targeting 7.1 and we don't want to have this argument again.

Throwing exception's may not be consistent right now, but it certainly
should be in the future. The transition to a new consistency has to start
somewhere.

--001a113eceb2a30453051c9fe4b3--