Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82940
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.99 as permitted sender)
Message-ID: <BLU436-SMTP1239F5D2F0BC14F0A8BF7B5E22F0@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <CAF+90c8NAROuCDgRajF4AN2oTc4fzmxTjtVC_OAQH=ZFm5N9Uw@mail.gmail.com>
Date: Tue, 17 Feb 2015 11:14:50 +0100
CC: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <CAF+90c-7w1fLqmffYvPRhmtt8rzESEpSmW8vfMD-YfLt1mG_8w@mail.gmail.com> <CAF+90c8NAROuCDgRajF4AN2oTc4fzmxTjtVC_OAQH=ZFm5N9Uw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: bobwei9@hotmail.com (Bob Weinand)

> Am 14.02.2015 um 00:25 schrieb Nikita Popov <nikita.ppv@gmail.com>:
>=20
> On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov <nikita.ppv@gmail.com> =
wrote:
>=20
>> Hi internals!
>>=20
>> During the PHP 5.6 development cycle I have proposed an RFC [1] that
>> suggested the use of exceptions instead of fatal errors in the =
engine. At
>> the time the proposal was declined, because the change was judged too
>> intrusive for a minor version.
>>=20
>> As such I'm re-proposing this RFC for inclusion in PHP 7:
>>=20
>>    https://wiki.php.net/rfc/engine_exceptions_for_php7
>>=20
>> The RFC text is essentially the same as previously, with the primary
>> difference being that parse errors are now converted to exceptions as =
well.
>> This was previously not possible due to limitations in the compiler =
design.
>>=20
>> Thanks,
>> Nikita
>>=20
>>  [1]: https://wiki.php.net/rfc/engine_exceptions
>>=20
>=20
> Feature freeze is not so far away now, so I'd like to bring this RFC =
up
> again and proceed to voting shortly. There are two primary open =
questions:
>=20
> * Subclassing: Should there be more specific subclasses of =
EngineException
> for particular errors?
> * Superclassing: Should EngineException inherit from Exception (and as
> such be subject to catch(Exception)) or should we introduce some kind =
of
> special super-class that is not caught by default (like
> Catchable/Throwable)?
>=20
> I don't think we can implement a high-quality subclassing scheme in a
> timeframe for PHP 7, as such I would suggest to postpone this (if we
> actually want to do it) to a later point in time. We can introduce
> subclasses without BC issues in a minor version.
>=20
> The question of whether EngineException should inherit from Exception =
is
> something we do have to consider now. Personally I prefer not =
introducing
> any special exception types that aren't caught by default. I think =
that
> would only make sense for errors that could occur literally everywhere
> (like memory limit or timeout), but these are not handled by this RFC =
for
> technical reasons. If someone has a strong opinion on this, I might =
make it
> a voting option.
>=20
> Commentary on these, and also any other relevant points is very =
welcome!
>=20
> Thanks,
> Nikita
>=20
> PS: The patch attached to the RFC is very outdated. I plan to only =
update
> it to current master once the RFC passes (if it does), as I already =
had to
> practically rewrite it a few times.

Hey,

For subclassing I totally agree that we should postpone this (if we want =
this at all).

I think EngineException should inherit from Exception. You usually only =
catch Exception in catch-all handlers to display, log etc. the =
backtraces. In all these cases, you're very likely to want to catch the =
EngineException too, without a second catch block where the catch body =
is duplicated.
I can't really think of a catch-all block where you'd explicitly don't =
want to handle EngineException. And if it'd really be the case, you =
still can do an instanceof check and rethrow if needed...

Thanks,
Bob=