Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86381 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33590 invoked from network); 25 May 2015 17:49:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 May 2015 17:49:21 -0000 Authentication-Results: pb1.pair.com header.from=dev@mabe.berlin; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=dev@mabe.berlin; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.167 cause and error) X-PHP-List-Original-Sender: dev@mabe.berlin X-Host-Fingerprint: 80.237.132.167 wp160.webpack.hosteurope.de Received: from [80.237.132.167] ([80.237.132.167:43454] helo=wp160.webpack.hosteurope.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 46/72-17853-0A063655 for ; Mon, 25 May 2015 13:49:21 -0400 Received: from dslb-088-073-137-171.088.073.pools.vodafone-ip.de ([88.73.137.171] helo=[192.168.178.27]); authenticated by wp160.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1YwwV3-0004h3-Hb; Mon, 25 May 2015 19:49:17 +0200 Message-ID: <5563609C.8020501@mabe.berlin> Date: Mon, 25 May 2015 19:49:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Aaron Piotrowski CC: internals@lists.php.net References: <971AB39D-1E20-43E8-9CF1-A7F67E3C14C3@icicle.io> <556221C7.8040809@mabe.berlin> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-bounce-key: webpack.hosteurope.de;dev@mabe.berlin;1432576161;5f2168e3; Subject: Re: [PHP-DEV] [RFC] Throwable Interface From: dev@mabe.berlin (Marc Bennewitz) On 05/24/2015 10:11 PM, Aaron Piotrowski wrote: > >> On May 24, 2015, at 2:08 PM, Marc Bennewitz wrote: >> >> Where are the new classes and the interface located if it's not in the global namespace or do I muss something? > Sorry if what I wrote wasn’t clear. Throwable, Error, TypeError, and ParseError will be built-in interfaces/classes in the root namespaces. So users will not be able to make classes with those exact names, but classes with those names in a non-global namespace (e.g., \Vendor\Package\TypeError) will still be possible. I’ve updated the RFC to make this clearer. Thanks > >> If I remember right the TypeException/TypeError will be thrown in some cases of internal functions with strict argument count. >> In my opinion a missing argument or to much arguments has nothing to do with the type and should have it's own Exception/Error class. > I believe this actually generates a warning, it does not throw an exception. However, this does remind me of another point: It is possible that more classes extending Error could be created in the future for different error reasons. Anything that throws an Error could later be changed to throw an object extending Error without a BC break. This is a separate issue though and could be discussed in a future RFC. Ok than I remember wrong. > Aaron Piotrowski Marc