Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76874
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53FBAD09.1080108@sugarcrm.com>
References: <CAF+90c_M7nKiVLYT0vWaq8wg==Yz0ZZC1V_ke=t71rpWqKPepA@mail.gmail.com>
	<CAF+90c-d6=rSN5Z-cngmEO-bheFF_0JR7iJ4uhFZWVMfRdL2Ug@mail.gmail.com>
	<53FB6D4C.9070705@php.net>
	<CAF+90c8+3Otfw3Mscm8FcNTObHr+_id6bDkLw7DW5xmATgRfkg@mail.gmail.com>
	<53FBAD09.1080108@sugarcrm.com>
Date: Tue, 26 Aug 2014 00:54:35 +0200
Message-ID: <CAF+90c99XLguDGbXs_hvu9Oz1UvRdCHj60rKaxW7u2u9dnOH5Q@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Sebastian Bergmann <sebastian@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c36fd22c695b05017c12a9
Subject: Re: [PHP-DEV] Re: [VOTE] Abstract Syntax Tree
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11c36fd22c695b05017c12a9
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 25, 2014 at 11:39 PM, Stas Malyshev <smalyshev@sugarcrm.com>
wrote:

> Hi!
>
> > I don't know if I will be implementing that ext myself. In any case,
> before
> > that can happen I will have to create another RFC for converting parse
> > errors into exceptions and making sure we don't leak memory on failed
> parse
>
> If we're talking the plunge of putting exceptions into the core engine,
> wouldn't it make sense to convert most of the fatal errors (especially
> the "catchable" ones) to exceptions too? Most of them (except for out of
> memory, timeouts and such) don't really require the engine to shut down,
> as it seems... So if we're already saying people will have to deal with
> exceptions in PHP engine anyway, maybe we could make it so that we could
> have unified handling of them?
>

I was planning to deal with parse exceptions separately because they
require special handling and larger changes to the parser. However I could
also apply those changes independently, as they are also useful for
avoiding leaks on failed eval()s. The actual exception can then be
introduced together with other exceptions for fatal errors.

Yeah, I think that's what I'm going to do, thanks for pointing this out :)

Nikita

PS: The AST branch is now merged into master.

--001a11c36fd22c695b05017c12a9--