Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87045
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: "'Aaron Piotrowski'" <aaron@icicle.io>,
	<internals@lists.php.net>
References: <7D73A3C7-F694-497B-9A9D-4F375F86B6A0@icicle.io>
In-Reply-To: <7D73A3C7-F694-497B-9A9D-4F375F86B6A0@icicle.io>
Date: Mon, 6 Jul 2015 12:06:34 +0200
Message-ID: <0ca201d0b7d3$72697240$573c56c0$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGdf19uUjzsqNYBQsS3JK6NDnjPep40pGvw
Content-Language: en-us
Subject: RE: [PHP-DEV] Error Subclasses
From: anatol.php@belski.net ("Anatol Belski")

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
>=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.

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