On Thu, 2003-03-27 at 17:58, Andi Gutmans wrote: > At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote: > >I've implemented an additional feature for type hints that will throw an > >exception instead of bailing out in case an incorrect type is passed. > I don't see any major advantage in doing this.
How about being able to handle errors in a clean and elegant way?
Exceptions make this very convenient.
Of course, it should not be done in a way to break backward
compatibility if at all possible.
> I think we should keep PHP error handling the same as in PHP 4 and
> leave exceptions in user-land.
This is a very bad idea. One of the points of exceptions is being able
to have a standardized way of handling errors. I also like the way Java
does it: if you don't catch the exceptions your code could throw, your
code won't even compile. Now, I am pretty certain that you would not be
happy if I said this would be neat to have in PHP. :-) Still, I think
it would be great to have it as a configuration directive, because it
really is a Good Thing to force programmers to handle errors properly...
> Otherwise we'll end up having an unmanageable hybrid because there's no way
> we're going to change the error-handling of the existing internal
> functions. The majority of our user base is still functional, please don't
> forget this. I feel that people here tend to forget that.
It is true that many people still write imperative (function-based)
code. But that is no argument for not making PHP a really, really good
Java-killer. And, standardized exceptions is really one of the things I
find absoutely best in Java. Yes, it is awkward in the beginning to
always have to try { } catch (or add Throws to your methods), but the
benefits are tremendeous.
Yes, the more I think about it I realize that this is big changes we are
talking about. Basically, if we were to make all PHP internal functions
throw exceptions on errors, we might as well make them all be static
methods in a global PHP object... and that would break all backward
compatibility. But maybe there would be a way to do it without breaking
all BC?
I hope this email will not start a long flamewar about why OOP is
bad/good. Some people will obviously hate it and others love it. But I
really, really do believe that if we want PHP to be the best programming
environment available, we need to take these issues into serious
consideration. Many of the OOP problems of PHP4 have already been fixed
in PHP5. Yet, there is still some room for improvement.
Maybe just have a big configuration switch called "php_oop" that is set
to "true" if the user prefers a OOP-based PHP, and "false" otherwise.
Possibly, and perhaps a better alternative, adding a new mime type
called "application/x-httpd-ohp" with file endings of .ohp, for
(puristic) object-oriented code. That might not actually be a bad idea,
because it could keep the best of both worlds.
Just my $0.02. ;-)
--
With all due respect,
Per Lundberg / Capio ApS
Phone: +46-18-4186040
Fax: +46-18-4186049
Web: http://www.capio.com
signature.asc
Description: This is a digitally signed message part
