Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87699
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain paragonie.com from 209.85.192.41 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAKws9z0Q2WMxAGVZAgz=noJbViqmEJb43SWo_fB6MTum3ptFDA@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>
Date: Mon, 10 Aug 2015 10:41:27 -0400
Message-ID: <CAKws9z2pKRHR0kaTgw=UhLLeUDPS8MpY70PCMsSwsFxJnPbAZw@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
From: scott@paragonie.com (Scott Arciszewski)

On Thu, Aug 6, 2015 at 4:52 AM, Niklas Keller <me@kelunik.com> wrote:
> Scott, could you setup a RFC with a vote, so we can decide?
>
> Nikita proposed those two options:
>
>> 1) Error is to be used in cases where an error is attributable to
>> programmer mistake.
>>
>>
>>
>> 2) Error signifies a failure condition that the programmer is discourage=
d
>> (and unlikely to want) to handle. It should only be dealt with at the to=
p
>> level.
>
>
> 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.
>
> Regards, Niklas

 ------------

 On Fri, Aug 7, 2015 at 1:38 AM, Aaron Piotrowski <aaron@icicle.io> wrote:
>
>> On Aug 6, 2015, at 3:52 AM, Niklas Keller <me@kelunik.com> wrote:
>>
>> Scott, could you setup a RFC with a vote, so we can decide?
>>
>> Nikita proposed those two options:
>>
>>> 1) Error is to be used in cases where an error is attributable to
>>> programmer mistake.
>>>
>>
>>
>>> 2) Error signifies a failure condition that the programmer is discourag=
ed
>>> (and unlikely to want) to handle. It should only be dealt with at the t=
op
>>> level.
>>
>>
>> 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_ resul=
t
>> in a failure, otherwise Exception.
>>
>> Regards, Niklas
>
> I=E2=80=99m in favor of 1), as this was my original intention of the Erro=
r branch of
> exceptions. Errors should be attributable to a programming mistake that s=
hould
> be corrected. Exception should be thrown for unexpected conditions that a=
re 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 m=
ethods 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 mod=
e.
>> 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 wi=
ll
>> still add one case where a different type is returned on error. This mak=
es
>> random_int from a function returning int, to a function returning int|nu=
ll.
>
> I would also be in favor of throwing TypeError from zpp calls in new func=
tions
> (and quite frankly, from zpp calls in all functions, including old functi=
ons).
>
> Regards,
> Aaron Piotrowski
>

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.)

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>