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. I think we should keep PHP
> error handling the same as in PHP 4 and leave exceptions in user-land.
> 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.
Well, the problem about E_ERROR is, of course, that it bails out instantaneously and there is no way to catch it in userland.
I consider calling a function with the wrong arguments a fatal error. A compiled language would usually barf already during the compilation stage. Therefore, I think E_ERROR is appropriate.
I unsterstand your arguments, though, but since type hints are for classes only ATM (it was argued against being able to hint simple, scalar types), we're in OO-land anyway; and there, Exceptions prevail over warnings and/or errors:)
I think even the slightly more advanced functional programs might like some of the OO encapsulation. But I think there's still a big difference between using a class to encapsulate a database object and starting to throw exceptions, using interfaces and so on. I don't want to force the average PHP developer in this direction and I'd like to stay consistent with today's E_ERROR handling.
Andi
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
