Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62770 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71508 invoked from network); 3 Sep 2012 23:27:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Sep 2012 23:27:18 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.143 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.143 smtp143.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.143] ([67.192.241.143:38961] helo=smtp143.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 27/FE-20751-5DC35405 for ; Mon, 03 Sep 2012 19:27:17 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 6157F3A039A; Mon, 3 Sep 2012 19:27:14 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id CE1753A0330; Mon, 3 Sep 2012 19:27:13 -0400 (EDT) Message-ID: <50453CD0.5080301@sugarcrm.com> Date: Mon, 03 Sep 2012 16:27:12 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Gustavo Lopes CC: "internals@lists.php.net" References: <5040DC47.8000305@ajf.me> <5040F4D9.80206@sugarcrm.com> <5042946A.80204@sugarcrm.com> <5042A7D6.7050001@lerdorf.com> <5045266F.7000303@sugarcrm.com> <47ddfb3c6842ca1fa92f6502e8d3504f@nebm.ist.utl.pt> In-Reply-To: <47ddfb3c6842ca1fa92f6502e8d3504f@nebm.ist.utl.pt> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Are exceptions allowed in php core? From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > to be gained vs. the additional risk. And there is little to no benefit > in a model where rewinding a closed iterator is allowed, so the > threshold for acceptable risk is very low. This is not a difficult case > at all, IMHO. We are discussing whether it should lead to the fatal error. I see no reason for that and declaring "it's not difficult" does not make a reason a bit clearer. There should be a reason for generating fatal error, and "this may be a bug" is not a reason enough, at least not in PHP, as long established practice in PHP clearly shows. > There is no strict technical reason for most fatals in PHP too. Except > maybe parser errors, you usually can abstain from doing whatever action > would cause the fatal instead of raising the fatal. Calling function > that does not exist or abstract method? Return NULL (like an invalid > call btw). Returning null is a legitimate function return, and there's no value that can not be legitimately returned from an existing function. Moreover, since unlike empty iterator, not calling a function is not normal (iterators can be legitimately empty, but function can not be legitimately non-existing) fatal error is a proper response to it. Of course, if we used exceptions, there could be an exception thrown instead, which is the same thing more or less. > IMO, this is perhaps your strongest argument. But 1) that was a bad > idea, 2) we're not really talking about the behavior of foreach(), we're > talking about the behavior of specific methods that may or may not be > called in the context of a foreach, in a hierarchy where exception > throwing is well established. So it's not really analogous. Sorry, but again I have a feeling that you are not satisfied in general with how PHP handles errors and want much more strictness there. Which is completely fine, but I must again emphasize that doing it by sneaking exceptions here and there into the core is not the right way to do it. If you want to change how PHP behaves, it should be done as a language-level principle change, and not being done by altering bits of random patches to behave how the "strict" people like and inconsistently with how the rest of PHP behaves. I would be happy to discuss it, I have a lot of issues with current error handling too, but we can not just ignore the established principles. If we have a behavior that can be used in two contexts and it is not consistent with one of them, it is not good to point out it may be consistent with another. Not throwing exception in this case is consistent with all other PHP - nothing requires that generator or iterator would throw exceptions on every problem. In fact, I do not believe any of the existing iterators throw on trying to iterate past the end. So not throwing will be consistent with everything. However, throwing will be inconsistent with foreach() usage pattern and only marginally consistent with other iterators - while they indeed throw exceptions, as far as I can see they don't do it in normal iteration scenarios, only when trying to pull something weird like accessing keys of invalid iterator or when using underlying functionality that fails. But as far as I can see you can not make any of existing SPL iterators to throw by repeatedly iterating over them. Even NoRewindIterator - which states "no rewind" in its name - does not throw when you try to repeatedly iterate over it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227