RE: [PECL-DEV] Delayed exception - SOLVED

Really strange. zend_throw_exception() shouldn't have anything to do with the return_value. The usual behavior is to call zend_throw_exception, and then return control to the PHP interpreter. Did you notice that zend_throw_exception() does not abort the current execution ? After throwing the exception, you must explicitely return control to the calling PHP environment, . For examples, you can look at the automap and PHK PECL extensions. Their utils.h file defines several macros that send exceptions and abort the current execution. I hope they can be useful in your case. Regards Francois > -----Message d'origine----- > De : Piotr Pokora [mailto:piotrek.pokora@gmail.com] > Envoyé : jeudi 13 mars 2008 19:37 > À : pecl-dev@lists.php.net > Objet : Re: [PECL-DEV] Delayed exception - SOLVED > > > Piotr Pokora writes: > > I think I found the source of the problem here. > It's PHPG_THROW_EXCEPTION macroo. > > > try{ > > new WindowTest(); > > } catch(Exception $e) { > > echo $e->getMessage(); > > } > > > > Output is: > > > > Fatal error: Uncaught exception 'Exception' with message 'DADA' > > > > I throw Exception and catch Exception. Why this error? > > Exception is "Uncaught" because it's not explicitly returned by function. > The line which throws it is: > zend_throw_exception(exception, message, 0 TSRMLS_CC); > While it should looks like this: > return_value = zend_throw_exception(exception, message, 0 TSRMLS_CC); > > I am not sure if it's misfeature but at least such pattern makes > exceptions *working* with signal emissions. > > Though... I wonder when I look at PHP5 standard extensions' code. > There are plenty of zend_throw_exception invocations without any > returned value being set. > > Is this desired API behaviour? > > Piotras > > -- > PECL development discussion Mailing List (http://pecl.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >