Re: Catchable - marking methods just like static?

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