Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87675
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain icicle.io designates 199.38.81.6 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
In-Reply-To: <CANUQDCgiJVackjoxDaPmZWn_wCcDAZ=BwvhDzdaXsLhSPFVeRA@mail.gmail.com>
Date: Fri, 7 Aug 2015 00:38:08 -0500
Cc: Scott Arciszewski <scott@paragonie.com>,
 Nikita Popov <nikita.ppv@gmail.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <99CE9AAF-E6E9-4D37-B462-E4A63139EAFB@icicle.io>
References: <CAKws9z25cW7MTFeSanYVJK64Lb1uJYm5JJ82h7DDG1Td+j3EuA@mail.gmail.com> <CAPwsocHaTtGjL8CAdzAvbSN2wZSGZ50SRC6MBNKO0WtXzAZu3g@mail.gmail.com> <CANUQDCgiJVackjoxDaPmZWn_wCcDAZ=BwvhDzdaXsLhSPFVeRA@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
From: aaron@icicle.io (Aaron Piotrowski)


> On Aug 6, 2015, at 3:52 AM, Niklas Keller <me@kelunik.com> wrote:
>=20
> Scott, could you setup a RFC with a vote, so we can decide?
>=20
> Nikita proposed those two options:
>=20
>> 1) Error is to be used in cases where an error is attributable to
>> programmer mistake.
>>=20
>=20
>=20
>> 2) Error signifies a failure condition that the programmer is =
discouraged
>> (and unlikely to want) to handle. It should only be dealt with at the =
top
>> level.
>=20
>=20
> I'm in favor of 2), I would phrase it like: Error should be used if a
> repetitive call with the same input parameters would _permanently_ =
result
> in a failure, otherwise Exception.
>=20
> Regards, Niklas

I=E2=80=99m in favor of 1), as this was my original intention of the =
Error branch of
exceptions. Errors should be attributable to a programming mistake that =
should
be corrected. Exception should be thrown for unexpected conditions that =
are not
due to programmer error, but instead things like IO or permission =
errors. I think
this is how exceptions thrown from core functions (and all functions or =
methods in
extensions) should be organized.

Based on this interpretation, random_int() should throw an Error if $min =
> $max
and random_bytes() should throw an Error if $length <=3D 0. =
random_bytes() and
random_int() should throw an Exception if random data cannot be =
generated.

Another quote from Nikita=E2=80=99s message to the prior thread:

> Another interesting aspect are the zpp calls. Currently these will =
throw a
> warning and return NULL in weak mode and throw a TypeError in strict =
mode.
> I wonder whether we should be using zpp_throw for new functions, so a
> TypeError is also thrown in weak mode. Continuing to use the old
> warning+NULL behavior was a BC concern, which we don't have for new
> functions. The reason why I think this is worth considering, is that =
if all
> other error conditions of a function already throw, then ordinary zpp =
will
> still add one case where a different type is returned on error. This =
makes
> random_int from a function returning int, to a function returning =
int|null.

I would also be in favor of throwing TypeError from zpp calls in new =
functions
(and quite frankly, from zpp calls in all functions, including old =
functions).

Regards,
Aaron Piotrowski