Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87059
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.163 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU6zj=xjPubeu8VtoFK42kTOT7N_d+UWtRCAHBkFLAC8dg@mail.gmail.com>
References: <7D73A3C7-F694-497B-9A9D-4F375F86B6A0@icicle.io>
	<CAEZPtU6zj=xjPubeu8VtoFK42kTOT7N_d+UWtRCAHBkFLAC8dg@mail.gmail.com>
Date: Tue, 7 Jul 2015 03:25:25 +0200
Message-ID: <CANUQDCihPNyFPgV=V+YMM+Wf04xobM-yHc3WMKN+rdP+zNFOJg@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Aaron Piotrowski <aaron@icicle.io>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113ad1c68dfbcb051a3ee56d
Subject: Re: [PHP-DEV] Error Subclasses
From: me@kelunik.com (Niklas Keller)

--001a113ad1c68dfbcb051a3ee56d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2015-07-07 2:22 GMT+02:00 Pierre Joye <pierre.php@gmail.com>:

> 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
> 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 th=
e
> 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 tryin=
g
> 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 we=
ll 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 speci=
fy
> 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 o=
f
> Errors are thrown from conditions that were already throwing Error object=
s.
>
> Very good job! Thanks.
>
> > I was hoping this could be merged before beta 1, though I=E2=80=99m not=
 sure 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,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'm with Anatol here. It's no BC break if we only introduce subtypes
instead of the parent type, but it would be a BC break afterwards if the
names we choose now do not then. It feels pretty rushed to get it in before
beta1 (which is the final feature freeze).

As errors shouldn't be caught except for logging, there's also little
benefit in rushing in subtypes them now. The only benefit that I can see is
the exception name as a short and concise error description. It's nothing
like Throwable, which needed that exception, because a later introduction
would have been a BC break.

Regards, Niklas

--001a113ad1c68dfbcb051a3ee56d--