Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61574
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.133 as permitted sender)
Message-ID: <50098D64.8090505@sugarcrm.com>
Date: Fri, 20 Jul 2012 09:55:00 -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
CC: PHP internals <internals@lists.php.net>
References: <5007D707.2070100@hoa-project.net> <64.87.18983.E6379005@pb1.pair.com> <500989A4.8090501@lsces.co.uk>
In-Reply-To: <500989A4.8090501@lsces.co.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Make try/catch brackets optinal
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

>> I've run into problems with brace-less blocks many, many times over
>> the years. Clearly, enough other people have as well that any serious
>> coding standard includes a clause requiring that all blocks use
>> braces. I see no reason to add another context in which braces could
>> be omitted.

Agree, no reason to mess with try/catch at all. However for if there's a
small number of cases where brace-less block if ok, e.g. usually I could
write something like:
foreach($arr as $item) {
  if(!good($item)) continue;
  do_stuff($item);
}

and it's not that bad to have it brace-less. However anything more than
one-term continue or return or break something like that and you want
braces. Of course, this does not apply to try/catch since nobody does
just "return" inside try-catch.

In any case, I don't see any reason to mess with the braces. There's no
problem we'd be solving and it will only bring trouble and more messy code.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227