Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:7774
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Wed, 11 Feb 2004 23:39:28 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <13882749781.20040211233928@marcus-boerger.de>
To: Andi Gutmans <andi@zend.com>
Cc: internals@lists.php.net, zeev@zend.com
In-Reply-To: <5.1.0.14.2.20040210122441.03928ed8@127.0.0.1>
References: <5.1.0.14.2.20040203143932.0733a0d0@localhost>
 <5.1.0.14.2.20040203143932.0733a0d0@localhost>
 <5.1.0.14.2.20040210122441.03928ed8@127.0.0.1>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] New exceptions mechanism
From: helly@php.net (Marcus Boerger)

Hello Andi,

it works now fine :-)

marcus

Tuesday, February 10, 2004, 11:24:55 AM, you wrote:

> Does this still segfault for you? It doesn't for me.

> Andi

> At 11:29 PM 2/4/2004 +0100, 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