Re: New exceptions mechanism

From: Date: Wed, 04 Feb 2004 23:50:15 +0000
Subject: Re: New exceptions mechanism
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-7598@lists.php.net to get a copy of this message
I submitted a fix for this (as I suspected, it appears to be more of a bug in zend_call_function() than a bug in the new exceptions mechanism)... I'm not 100% sure about this fix as I didn't have time to investigate it too much, but it appears to be correct, and I wanted to allow you to go on testing :) I'll check into it further tomorrow. 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:helly@php.net


« previous php.internals (#7598) next »