Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62059 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1052 invoked from network); 6 Aug 2012 04:23:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Aug 2012 04:23:33 -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.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:44528] helo=smtp143.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E4/25-03102-2C64F105 for ; Mon, 06 Aug 2012 00:23:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 8E3BF1801FE; Mon, 6 Aug 2012 00:23:27 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp24.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 2A6661802AA; Mon, 6 Aug 2012 00:23:27 -0400 (EDT) Message-ID: <501F46BE.4040407@sugarcrm.com> Date: Sun, 05 Aug 2012 21:23:26 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ferenc Kovacs CC: PHP Internals References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Error handling brainstorming From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Basically Etienne mentioned that the original issue was a good example why > would we reconsider throwing exceptions from the core, which is currently > discouraged.[2] > Stan replied with the idea of turning the current error handling mechanism > in php into using Exceptions for everything, but keeping some error types > as is/uncatchable. [3] Exceptions are different from PHP errors. For example, if you try to open a file and the file isn't there, throwing exception is a very annoying behavior (yes I know some languages do that, IMO it's wrong). The reason is that it's pretty normal and within normal set of situations to which code should be prepared, so you will either have to obsessively wrap everything with try/catch blocks or do exception typing like Java does. Both options are quite annoying. I think it's much better to just open file and check if the result is OK. Converting it to exception doesn't really improve situation, as if downstream code didn't handle it the upstream probably won't know what to do with that exception either. This leads to code like try { whatever(); } catch(Exception e) {}. I saw tons of that in Java. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227