Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84017 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 89804 invoked from network); 27 Feb 2015 15:29:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2015 15:29:13 -0000 Authentication-Results: pb1.pair.com smtp.mail=guilhermeblanco@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=guilhermeblanco@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.182 as permitted sender) X-PHP-List-Original-Sender: guilhermeblanco@gmail.com X-Host-Fingerprint: 209.85.213.182 mail-ig0-f182.google.com Received: from [209.85.213.182] ([209.85.213.182:33894] helo=mail-ig0-f182.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 62/06-32582-84D80F45 for ; Fri, 27 Feb 2015 10:29:13 -0500 Received: by igal13 with SMTP id l13so1039821iga.1 for ; Fri, 27 Feb 2015 07:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IFey5rtHsgxuhKIBAR1zxubhECpCOmCLNNHDLJeYRCY=; b=wZN1rZzVs9EaIdTHgtwhknFBgzgGAlRV2Whsuu/F7DJ+PcPI/qC+RaYljOD6q2sdBH hrG2M/TNqaDf8AjqqydRI4n3XroallbqEur879STq3zSdMac/v4qA8ruvLyMJueGNF7M d/8etDR5w2y7ydR/Dq2VmXPt6Cx9a22gIVZ8I503cl8FxTBMih5YzldWlI9FrKtavC+w /7XcmSKD2OjtdAGdRtXw55+4pGDafn/OCm8jDAUXafJ1c6ii1yQ7BcyFgCJS+i7ZofCV sqBywgaMnt4D/5Ytuwcg6ZUoF5nOQw6acsluhpDfd0zNOOmfaZfHN9rD0aNlqArP20eC zV8Q== X-Received: by 10.42.39.147 with SMTP id h19mr15842838ice.91.1425050949795; Fri, 27 Feb 2015 07:29:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.83.134 with HTTP; Fri, 27 Feb 2015 07:28:49 -0800 (PST) In-Reply-To: <54F0839C.3010700@seld.be> References: <54F07FC7.8050901@php.net> <54F0839C.3010700@seld.be> Date: Fri, 27 Feb 2015 10:28:49 -0500 Message-ID: To: Jordi Boggiano Cc: PHP internals Content-Type: multipart/alternative; boundary=90e6ba61464ca668ba05101387fc Subject: Re: [PHP-DEV] [VOTE] Exceptions in the engine From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com") --90e6ba61464ca668ba05101387fc Content-Type: text/plain; charset=UTF-8 +1 on Sebastian's suggestion. =) I volunteer to either update the RFC or create a new one to resolve this once "Exceptions in the engine" passes (which looks like a reality already to me). Just tell me which approach I should take and I'll happily write the RFC. []s, On Fri, Feb 27, 2015 at 9:47 AM, Jordi Boggiano wrote: > On 27/02/2015 14:31, Sebastian Bergmann wrote: > >> Am 23.02.2015 um 19:15 schrieb Nikita Popov: >> >>> Voting on the engine exceptions RFC, which proposes to convert existing >>> fatal and recoverable fatal errors into exceptions, has opened: >>> >>> https://wiki.php.net/rfc/engine_exceptions_for_php7#vote >>> >>> The primary vote requires a 2/3 majority, as this is a language change. >>> >>> A second vote will decide whether to use a BaseException based >>> inheritance >>> hierarchy. This vote uses a simple majority. >>> >> >> I have voted yes on "Allow exceptions in the engine and conversion of >> existing fatals?" and no on "Introduce and use BaseException?" and >> would like to elaborate on the latter. >> >> I am sorry that I was unable to raise this concern earlier (did not >> really become aware of the RFC before it was put to the vote), but I >> would prefer the following: >> >> * Introduce a Throwable interface >> * Let Exception implement the Throwable interface >> * Introduce an Error class that implements the Throwable interface >> * Use Error class as base class for exceptions raised by the engine >> >> This would be along the lines of what Java does. >> > > +1 on that, and as it seems the BaseException is going to pass, it might > be good to quickly draft another RFC to amend that part. > > It seems people in general favor the fact that catch(Exception $e) does > not catch those new engine exceptions, but there hopefully would not be > much resistance against a cleaner scheme than a BaseException class. > > Also the Error (and possibly Throwable) class/interface might be put in a > PHP namespace and then we avoid any potential BC issues, but that's perhaps > another voting point :) > > Cheers > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --90e6ba61464ca668ba05101387fc--