On 12 Apr 2004 at 12:05, Andi Gutmans wrote:
> I agree it's a problem, but as you know, for BC reasons we can't make all > internal functions throw exceptions. I do suggest however, that new object > oriented extensions throw exceptions in object context. This isn't a BC > break and makes sense as it's used in an object-oriented context. > In any case, I understand that throwing an exception from user- land error > handling works as expected so this can partially solve the problem with > internal functions too. > > Andi
The problem with exception thrown by a user-land error handler is to distinguish real exceptions that break the execution from informative warnings.
I have just experienced this while playing around with XML Schema validation and 5.0.0b4. The current implementation always triggers two warnings telling 'Unimplemented block at xmlschemas.c:2245'. Furthermore, every validation failure is reported using PHP warnings.
That's why it is impossible to use a "user-land exception thrower" with schema validation at the moment. I don't know if it is the only extension misusing the errror handling mechanism...
Yeah, I think the way things are today, there is no way of doing this well.
I think that PHP should stay the way it is. If there are certain OOP extension writers who want to support exceptions I think there's no reason they shouldn't do so. It might also be possible to allow setting a flag in the constructor which tells the OOP extension if the developer wants exceptions or zend_error's.
All in all, as we're not writing the language from scratch on day 1, I don't see a way to solve this problem very well.
Andi
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
