Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67197 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 27751 invoked from network); 29 Apr 2013 16:26:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Apr 2013 16:26:51 -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 108.166.43.91 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.91 smtp91.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.91] ([108.166.43.91:52896] helo=smtp91.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 81/F0-23191-A4F9E715 for ; Mon, 29 Apr 2013 12:26:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 80E63140A14; Mon, 29 Apr 2013 12:26:47 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id AC4F7140A3F; Mon, 29 Apr 2013 12:26:46 -0400 (EDT) Message-ID: <517E9F47.4080100@sugarcrm.com> Date: Mon, 29 Apr 2013 09:26:47 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= CC: Julien Pauli , PHP Internals References: <1367221266.2723.181.camel@guybrush> In-Reply-To: <1367221266.2723.181.camel@guybrush> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Continued try blocks From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > this has quite a few issues and feels like abusing exceptions for > regular control flow. > The primary issue is that "throw" is a terminating operation. A I agree. If your code can handle the problem, it should not throw. If it throws, the control should not go back there, since the code already gave up and declared it can not continue doing whatever it was doing. Exceptions are meant to handle exceptional situations, not serve as a kind of goto with objects, IMO, and if the code threw an exception, it should be done. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227