Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87657
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain paragonie.com from 209.85.192.54 cause and error)
MIME-Version: 1.0
Date: Wed, 5 Aug 2015 19:55:14 -0400
Message-ID: <CAKws9z25cW7MTFeSanYVJK64Lb1uJYm5JJ82h7DDG1Td+j3EuA@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Recap - Core functions throwing exceptions in PHP7
From: scott@paragonie.com (Scott Arciszewski)

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>