Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:76872 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34269 invoked from network); 25 Aug 2014 21:39:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Aug 2014 21:39:19 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.91 smtp91.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.91] ([108.166.43.91:34208] helo=smtp91.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 35/BC-08882-50DABF35 for ; Mon, 25 Aug 2014 17:39:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 763B680914; Mon, 25 Aug 2014 17:39:15 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp12.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 1CDF5804FA; Mon, 25 Aug 2014 17:39:15 -0400 (EDT) X-Sender-Id: smalyshev@sugarcrm.com Received: from Stass-MacBook-Pro.local ([UNAVAILABLE]. [74.85.23.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.2.10); Mon, 25 Aug 2014 21:39:15 GMT Message-ID: <53FBAD09.1080108@sugarcrm.com> Date: Mon, 25 Aug 2014 14:39:21 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Nikita Popov , Sebastian Bergmann CC: PHP internals References: <53FB6D4C.9070705@php.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: [VOTE] Abstract Syntax Tree From: smalyshev@sugarcrm.com (Stas Malyshev) 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? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/