Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87058
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <7D73A3C7-F694-497B-9A9D-4F375F86B6A0@icicle.io>
References: <7D73A3C7-F694-497B-9A9D-4F375F86B6A0@icicle.io>
Date: Tue, 7 Jul 2015 07:22:27 +0700
Message-ID: <CAEZPtU6zj=xjPubeu8VtoFK42kTOT7N_d+UWtRCAHBkFLAC8dg@mail.gmail.com>
To: Aaron Piotrowski <aaron@icicle.io>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Error Subclasses
From: pierre.php@gmail.com (Pierre Joye)

hi Aaron,

On Mon, Jul 6, 2015 at 1:15 PM, Aaron Piotrowski <aaron@icicle.io> wrote:
> Hello everyone!
>
> I recently pushed changes that eliminated E_EXCEPTION and allows an excep=
tion type to be provided for what were fatals in PHP, while still falling b=
ack 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 Identi=
fierError.
>
> 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 suc=
h 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 inc=
orrect 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.

Very good job! Thanks.

> I was hoping this could be merged before beta 1, though I=E2=80=99m not s=
ure if the time table is too tight.


In any case you may like to start a RFC already, no matter if which
versions it targets.

About 7.0 in general, naming and conventions are something I like to
see solved in 7.0. I do not think it affects stability in any way and
should not delay the final release date. One argument in favor of such
exceptions  (if approved by RFC votes) is that dealing with such
changes or additions for the core languages in minor versions is
somehow more painful for our users.

In any case, please go for a RFC and see what gets out of it :)

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org