Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62763 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 41210 invoked from network); 3 Sep 2012 21:44:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Sep 2012 21:44:01 -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:44320] helo=smtp113.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6B/28-20751-F9425405 for ; Mon, 03 Sep 2012 17:44:01 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp21.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id B396D2405E7; Mon, 3 Sep 2012 17:43:56 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp21.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 027002405DA; Mon, 3 Sep 2012 17:43:55 -0400 (EDT) Message-ID: <5045249B.4070605@sugarcrm.com> Date: Mon, 03 Sep 2012 14:43:55 -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: Pierre Joye CC: PHP Internals References: <5040DC47.8000305@ajf.me> <5040F4D9.80206@sugarcrm.com> <5042946A.80204@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Are exceptions allowed in php core? From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > They are seen and promoted as core features. Whether we like that idea > or not is not really relevant. We messed that up by making most of the > "Standard" PHP Library an extension for only political and licensing > reasons. I think you using "core" here in two difference meanings, and the question of political and licensing reasons is completely irrelevant to current discussion. The question is that we have language core (keywords, syntax constructs, etc.) and we have various APIs. Unfortunately, due to disagreement among PHP developers, there's no consistent policy among APIs on the question of how to handle errors. However, there is a consistent policy about how to do it when we're talking about core PHP constructs - keywords, language syntax, etc. - that we do not use exceptions there. > We can't really change existing code without breaking everything out > there. So we somehow have to do it on a case by case basis or for new > stuff only. We have to have clear policy that can be understood by users. Doing it on a whim of a person that submits particular patch was what we were doing before, and it didn't work very well for us. The consensus by this point was that PHP keywords, language constructs, etc. do not throw exceptions (the unfortunate patch of 2005 aside). If you want to change this - fine, please propose a consistent policy that changes it, let's agree on it and adopt it. But doing it in random places just because it seemed convenient at this moment IMO is not a good idea. It is IMO exactly what we are trying to fix. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227