Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62764 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43083 invoked from network); 3 Sep 2012 21:51:49 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Sep 2012 21:51:49 -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 67.192.241.113 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.113 smtp113.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.113] ([67.192.241.113:40761] helo=smtp113.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6E/88-20751-37625405 for ; Mon, 03 Sep 2012 17:51:48 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp21.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 65AF32402B8; Mon, 3 Sep 2012 17:51:45 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp21.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id B43F52401B9; Mon, 3 Sep 2012 17:51:44 -0400 (EDT) Message-ID: <5045266F.7000303@sugarcrm.com> Date: Mon, 03 Sep 2012 14:51:43 -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: Derick Rethans , Rasmus Lerdorf , Pierre Joye , PHP Internals References: <5040DC47.8000305@ajf.me> <5040F4D9.80206@sugarcrm.com> <5042946A.80204@sugarcrm.com> <5042A7D6.7050001@lerdorf.com> In-Reply-To: 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! > I've replied here: > http://www.mail-archive.com/internals@lists.php.net/msg60706.html I have a feeling you're concocting a very far-reaching scenarios and making a lot of unbased assumptions there to arrive to pre-defined conclusions. Any programming error can cost a business money, and any problem can be fitted with scenario when it leads to blowing up whole world in the flames of global catastrophe, given enough imagination and wild enough assumptions. However, I do not see any technical reason - not involving far-reaching assumptions following from nowhere - that require repeated generation produce a fatal error. So far all the explanations seem to be to the tune of "because it's so bad!" but I don't see how it's worse than any other fault - such as failing to open the file, database returning no results because of wrong query, etc. We do not produce fatal errors on all of these cases - in fact, we produce fatal errors only when we know there's no reasonable way to go on. I still do not see why just returning empty iterator with suitable warning does not fit the pattern of all exceptional situations we have in PHP that are handled in a similar way. For foreach() specifically, for example, you can put there invalid - non-iterable - value, and it won't be a fatal error. Why non-iterable value from generator should be a fatal error? I think it makes sense to treat it exactly like foreach() treats non-iterable values. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227