Hello Andi,
Tuesday, February 3, 2004, 2:01:12 PM, you wrote:
> Hi,
> We rewrote the exception support. It fixes a few limitations and bugs in
> the old implementation, and allows exceptions to 'fire' much earlier than
> before.
> Generally, with the new mechanism, you're not supposed to touch
> EG(exception) directly, except for when you want to check whether there was
> an exception (you're not allowed to directly modify EG(exception)).
> - Generally, to throw an exception you need to use
> zend_throw_exception(). If you have special needs, and for some reason you
> wish to bypass zend_throw_exception(), you can use
> zend_throw_exception_internal(). Again, generally you shouldn't have to do
> that, though.
> - The new mechanism allows PHP to handle exceptions as soon as we return to
> the context of the execute loop. Exceptions still cannot be caught inside
> your extension code, as they can only be handled reliably in the context of
> execute(). For example, if an exception is thrown in a callback function
> that's called by array_walk(), it will only be caught when array_walk()
> returns.
> - Functions like array_walk() (typically functions that use
> zend_call_function() or call_user_function_ex()) should decide whether they
> want to abort when there is an exception, or ignore it. If you choose to
> abort, and let the exception propagate up, then you should simply return
> back as soon as you can. As soon as it reaches the execute loop - the
> exception will be handled (i.e., if there's a corresponding catch block it
> will be executed, or otherwise, the stack will unwind).
> If you choose to ignore it - you should call
> zend_clear_exception(TSRMLS_C). Note that you should make your choice and
> behave accordingly BEFORE making any further calls to PHP functions (or any
> code that may throw an exception).
> - To check whether there was an exception, you should still use the same
> method as before (check whether EG(exception) is not NULL), but again, you
> may not change it directly under any circumstances.
> Note - this (most probably) breaks the current implementation of
> set_exception_handler() so whoever is responsible for that piece of code
> please look into it, and ask us if you have any questions.
> Andi
The new exception implementation looks a bit nicer but needs some
tweaks. Try this code:
php -r 'reflection_class::export("xyz");'
which dirctly segfaults. What happens is that the class xyz does not exist
and reflection api throws an exception which results in a SEGV.
--
Best regards,
Marcus mailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
