Re: Recap - Core functions throwing exceptions in PHP7
| From: | Aaron Piotrowski | Date: | Fri, 07 Aug 2015 05:38:08 +0000 |
| Subject: | Re: Recap - Core functions throwing exceptions in PHP7 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-87675@lists.php.net to get a copy of this message | ||
> 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 discouraged
>> (and unlikely to want) to handle. It should only be dealt with at the top
>> 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
I’m 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 <= 0. random_bytes() and
random_int() should throw an Exception if random data cannot be generated.
Another quote from Nikita’s 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