Reply inline..
On Wednesday, April 04, 2012 10:29 AM, Adam Harvey wrote:
On 4 April 2012 10:02, Alan Knowles<a...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
