Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59351
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain akbkhome.com designates 202.81.246.113 as permitted sender)
Message-ID: <4F7C1ED8.6090706@akbkhome.com>
Date: Wed, 04 Apr 2012 18:13:44 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Adam Harvey <aharvey@php.net>, 
 PHP Internals <internals@lists.php.net>
References: <4F7BABC8.7040904@akbkhome.com> <CADajX4BaMt+031Do4P6e4PLHNFaDeF92opiSBORt60MKOcR-Rg@mail.gmail.com>
In-Reply-To: <CADajX4BaMt+031Do4P6e4PLHNFaDeF92opiSBORt60MKOcR-Rg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Catchable - marking methods just like static?
From: alan@akbkhome.com (Alan Knowles)

Reply inline..
On Wednesday, April 04, 2012 10:29 AM, Adam Harvey wrote:
> On 4 April 2012 10:02, Alan Knowles<alan@akbkhome.com>  wrote:
>> PHP enforces rules like $this can not be used in a method marked 'static'.
>> So why not flag methods (and internal functions) with a flag that indicates
>> they can throw things. Since PHP is not a compiled language we can not pick
>> up 'all' of the potential scenarios, but even if E_NOTICE's pick up 80% it
>> would make code considerably more maintainable.
> I don't like this. It's basically the equivalent of Java's "throws
> Exception" antipattern[0] with none of the claimed benefits of
> checked, fine grained exception specification (which I'm dubious about
> in general, particularly having also used C++'s static exception
> specifiers, which are even worse than Java's dynamic ones).
Yes, it seems that anti-pattern document is actually the current 
specification for PHP's exceptions design. Naming the exceptions that 
could be thrown is probably not a bad idea, however as you say the 
syntax change is a problem..

> There are issues with both backward and forward compatibility here:
> assuming this was in PHP 5.5, you could effectively no longer write
> code that was E_STRICT/E_NOTICE clean in both PHP 5.4 and 5.5 — you
> can't add catchable to functions in PHP 5.4 because it's not a
> keyword, but you can't throw an exception in PHP 5.5 without it unless
> you're prepared to incur a notice.
The other alternative would be to use docblocks, and testing for 
"@throws ... \n" if a function throws an exception.  This may mean that 
this would be feasible as an extension, as it would not have modify the 
parser syntax. and could be implemented on PHP 5.3 or less....

just like you would set error_reporting(E_ALL) at the start of the code, 
you could add exception_reporting(E_ALL);

> Also, I already know how to use exceptions, and write clean code.
All I will say to that is  "So do I!" ;) however knowing how to, and 
actually doing it are two different things (I'm a human who makes 
mistakes, so I'd rather get all the help I can)

>   I
> don't really want to have to add catchable to all of the functions
> I've written that may throw — or may call library functions that may
> throw — when I upgrade to PHP 5.5. It's a lot of work, and given that
> a lot of libraries now use exceptions, a lot of developers would end
> up almost mechanically adding catchable to pretty much every function,
> which loses any minimal code quality advantage that might exist.
Which sounds like a extension using docblocks may be a good place for 
this.. I just wonder how you can stop the behavior of all developers 
just adding @throws Exception - unless you insist on it being a 'named' 
exception other than the base one..


> Exception specifications in general don't feel very PHPish to me, but
> that would be a different discussion. Catchable, as a limited form of
> exception specification, feels even less useful than that.
Not a great fan of them either, but if we to use them at least give me 
some of the classic PHP tools (warnings) to make them less painfull..

Regards
Alan
>
>> Anyway... flame away ;)
> Sorry, I guess I kind of did. It's nothing personal. :)
>
> Adam
>
> [0] http://today.java.net/article/2006/04/04/exception-handling-antipatterns#throwingException
>