Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82942 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 74989 invoked from network); 17 Feb 2015 10:31:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Feb 2015 10:31:51 -0000 Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.86 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.86 blu004-omc2s11.hotmail.com Received: from [65.55.111.86] ([65.55.111.86:49409] helo=BLU004-OMC2S11.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 86/31-01961-69813E45 for ; Tue, 17 Feb 2015 05:31:51 -0500 Received: from BLU436-SMTP195 ([65.55.111.72]) by BLU004-OMC2S11.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 17 Feb 2015 02:30:18 -0800 X-TMN: [EvEkEDN/uuxEAqUz9vdp35tbaH+A3bwh] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_4FA7DE1D-63D4-47A4-9501-843DE713959C" MIME-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) In-Reply-To: Date: Tue, 17 Feb 2015 11:30:12 +0100 CC: Nikita Popov , PHP internals References: To: Benjamin Eberlei X-Mailer: Apple Mail (2.1990.1) X-OriginalArrivalTime: 17 Feb 2015 10:30:16.0098 (UTC) FILETIME=[B84A6020:01D04A9C] Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine From: bobwei9@hotmail.com (Bob Weinand) --Apple-Mail=_4FA7DE1D-63D4-47A4-9501-843DE713959C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" > Am 17.02.2015 um 11:21 schrieb Benjamin Eberlei : > On Tue, Feb 17, 2015 at 11:14 AM, Bob Weinand > wrote: > > Am 14.02.2015 um 00:25 schrieb Nikita Popov >: > > > > On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov > wrote: > > > >> Hi internals! > >> > >> 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. > >> > >> As such I'm re-proposing this RFC for inclusion in PHP 7: > >> > >> https://wiki.php.net/rfc/engine_exceptions_for_php7 = > >> > >> 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. > >> > >> Thanks, > >> Nikita > >> > >> [1]: https://wiki.php.net/rfc/engine_exceptions = > >> > > > > 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: > > > > * 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)? > > > > 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. > > > > 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. > > > > Commentary on these, and also any other relevant points is very = welcome! > > > > Thanks, > > Nikita > > > > 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. >=20 > Hey, >=20 > For subclassing I totally agree that we should postpone this (if we = want this at all). >=20 > 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... >=20 > I think that would be a huge BC break. I see a lot of code just = catching \Exception at various customers and opensource projects. = EngineException should not be a child of Exception. >=20 > Thanks, > Bob No, it isn't a BC break. It would only affect broken things, which = generate fatals as of now. Working applications are not affected and that way it does not break BC. So, I don't see any harm here in superclassing EngineException. Bob= --Apple-Mail=_4FA7DE1D-63D4-47A4-9501-843DE713959C--