Re: [Zend Engine 2] Type hints revisited [IllegalArgumentException instead of E_ERROR]
| From: | Andi Gutmans | Date: | Thu, 27 Mar 2003 17:57:42 +0000 |
| Subject: | Re: [Zend Engine 2] Type hints revisited [IllegalArgumentException instead of E_ERROR] | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-384@lists.php.net to get a copy of this message | ||
At 06:13 PM 3/27/2003 +0100, Timm Friebe wrote:
On Thu, 2003-03-27 at 17:58, Andi Gutmans wrote: At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote: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'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 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