Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87049
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Bob Weinand'" <bobwei9@hotmail.com>
Cc: "'Aaron Piotrowski'" <aaron@icicle.io>,
	<internals@lists.php.net>
References: <7D73A3C7-F694-497B-9A9D-4F375F86B6A0@icicle.io> <0ca201d0b7d3$72697240$573c56c0$@belski.net> <BLU437-SMTP10AE3C0D27EFC702B83C04E2930@phx.gbl>
In-Reply-To: <BLU437-SMTP10AE3C0D27EFC702B83C04E2930@phx.gbl>
Date: Mon, 6 Jul 2015 15:29:06 +0200
Message-ID: <0d5a01d0b7ef$bd684b60$3838e220$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGdf19uUjzsqNYBQsS3JK6NDnjPegJ6HYy5AbNj6ameE25BAA==
Content-Language: en-us
Subject: RE: [PHP-DEV] Error Subclasses
From: anatol.php@belski.net ("Anatol Belski")

Hi Bob,

> -----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>:
> >
> > Hi Aaron,
> >
> >> -----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
> >>
> >> Hello everyone!
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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>
> >>
> >> 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.
> >>
> >> This patch introduces no functional changes, only more specific =
types
> >> of Errors are thrown from conditions that were already throwing =
Error
> objects.
> >>
> >> I was hoping this could be merged before beta 1, though I=E2=80=99m =
not sure
> >> if the time table is too tight.
> >>
> > 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.
> >
> > 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.
> >
> > Regards
> >
> > 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.

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.

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.

Regards

Anatol