Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87057
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 \(2098\))
In-Reply-To: <0d5a01d0b7ef$bd684b60$3838e220$@belski.net>
Date: Mon, 6 Jul 2015 15:13:02 -0500
Cc: Bob Weinand <bobwei9@hotmail.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <9DDE3E72-7090-41D4-AA75-C7E0D9CE1DCE@icicle.io>
References: <7D73A3C7-F694-497B-9A9D-4F375F86B6A0@icicle.io> <0ca201d0b7d3$72697240$573c56c0$@belski.net> <BLU437-SMTP10AE3C0D27EFC702B83C04E2930@phx.gbl> <0d5a01d0b7ef$bd684b60$3838e220$@belski.net>
To: Anatol Belski <anatol.php@belski.net>
Subject: Re: [PHP-DEV] Error Subclasses
From: aaron@icicle.io (Aaron Piotrowski)

Hi Anatol,

> On Jul 6, 2015, at 8:29 AM, Anatol Belski <anatol.php@belski.net> =
wrote:
>=20
> Hi Bob,
>=20
>> -----Original Message-----
>> From: Bob Weinand [mailto:bobwei9@hotmail.com]
>> Sent: Monday, July 6, 2015 2:59 PM
>> To: Anatol Belski
>> Cc: Aaron Piotrowski; internals@lists.php.net
>> Subject: Re: [PHP-DEV] Error Subclasses
>>=20
>> Hey Anatol
>>=20
>>> Am 06.07.2015 um 12:06 schrieb Anatol Belski =
<anatol.php@belski.net>:
>>>=20
>>> Hi Aaron,
>>>=20
>>>> -----Original Message-----
>>>> From: Aaron Piotrowski [mailto:aaron@icicle.io]
>>>> Sent: Monday, July 6, 2015 8:16 AM
>>>> To: internals@lists.php.net
>>>> Subject: [PHP-DEV] Error Subclasses
>>>>=20
>>>> Hello everyone!
>>>>=20
>>>> I recently pushed changes that eliminated E_EXCEPTION and allows an
>>>> exception type to be provided for what were fatals in PHP, while
>>>> still falling back to an E_ERROR if necessary.
>>>>=20
>>>> Since more specific Error classes can be thrown, I'd like to =
propose
>>>> the following additions to the Error tree of exceptions: =
AccessError and
>> IdentifierError.
>>>>=20
>>>> AccessError - Thrown when trying attempting to call a public,
>>>> private, or abstract method, when statically calling a non-static
>>>> method, or trying to use self::, parent::, or static:: outside of a =
class.
>>>> IdentifierError - Thrown when referencing an undefined function,
>>>> method, class, constant, etc.
>>>>=20
>>>> I=E2=80=99ve created a patch that implements the exceptions above =
as well as
>>>> updating all the related tests:
>>>> https://github.com/trowski/php-src/tree/error-subclasses
>>>> <https://github.com/trowski/php-src/tree/error-subclasses>
>>>>=20
>>>> This patch also broadens the usage of TypeError to include =
conditions
>>>> such as calling a method on a scalar, passing a value that does not
>>>> specify a callback when one is expected, and various other =
conditions
>>>> based on an incorrect type that otherwise are throwing plain Error =
objects.
>>>>=20
>>>> This patch introduces no functional changes, only more specific =
types
>>>> of Errors are thrown from conditions that were already throwing =
Error
>> objects.
>>>>=20
>>>> I was hoping this could be merged before beta 1, though I=E2=80=99m =
not sure
>>>> if the time table is too tight.
>>>>=20
>>> Thanks for the ping. While I find the idea about more specific =
exceptions
>> correct, I would not recommend merging it in beta1. Reason - we have =
no big
>> time now to verify the patch completeness, to discuss the exception =
names and
>> areas where it's applicable.
>>>=20
>>> IMHO if it goes in, it has to be complete and well verified, maybe =
also voted
>> (regarding namings). As the area is very public and if we find any =
issues later and
>> have to rename/rework the exception names, etc. - it would be bad. So =
7.1
>> might be a better place to target. Technically it would be anyway =
worky as those
>> specialized extension classes will have the same parent.
>>>=20
>>> Regards
>>>=20
>>> Anatol
>>=20
>> I like what Aaron did here.
>>=20
>> I really think that should target 7.0. It's actually not breaking =
anything (really just
>> changing the exception names).
>> And I really think we should have a proper Error hierarchy at the =
release of PHP
>> 7.0. Considering it especially one of *the* features of 7.0.
>>=20
>> But I think, at end of beta 2 or so, we really should do a final =
review of all the
>> Errors in order to ensure everything is aptly named and used.
>>=20
> Thanks for the feedback. That's what I said as well - the idea is =
correct. Unfortunately it is too late. Just to remind - Trowable was too =
late as well by the time no more new RFCs was allowed. But as it was =
important and still acceptable in the alpha phase, so there was an =
exception for the exception RFC. This gives a good base to for further =
improvements.
>=20
> Now with actual subject - it's has nothing to do with the Trowable =
directly as it's in. However I don't think it's to decide by me, you or =
anyone else alone, whether the names fit good. Also in such a short =
period it's hard to check whether alle the needed places are touched and =
everything is ok. These are two main concerns preventing this to go in, =
IMHO.
>=20
> And we cannot target beta2 because it's a feature freeze already =
tomorrow when beta1 is tagged. One can argue, sure ... but some when =
there should be a clean cut. Then we should be working on fixing bugs =
and stabilizing the codebase. This PR is not a bug fix. Thus, 7.1 - this =
well thought and good tested feature would be welcome there. Starting =
with the time we've branched the 7.0 dev branch (middle September), the =
door is popen for any good features and RFCs. Now, having what we have - =
Error where it is, nothing is lost, as AnotherError extends Error.
>=20
> Regards
>=20
> Anatol
>=20
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

There are no functional issues with the patch, since as Bob pointed out, =
it is only changing the names of the exceptions thrown.

I agree that if beta 1 is to be the feature freeze then this will have =
to wait. There certainly is not enough time if we want to discuss naming =
or the situations where each type of Error is thrown.

I see no problem with waiting on this until 7.1 as long as introducing =
subclasses of Error and throwing those instead of a plain Error is not =
considered a BC break.

Regards,
Aaron