Zeev
At 00:29 05/02/2004, Marcus Boerger wrote:
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
