Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:7598
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Reply-To: zeev@zend.com
Message-ID: <5.1.0.14.2.20040205014838.07ab48f0@localhost>
Date: Thu, 05 Feb 2004 01:50:15 +0200
To: Marcus Boerger <helly@php.net>
Cc: Andi Gutmans <andi@zend.com>,internals@lists.php.net
In-Reply-To: <70-447866953.20040204232959@marcus-boerger.de>
References: <5.1.0.14.2.20040203143932.0733a0d0@localhost>
 <5.1.0.14.2.20040203143932.0733a0d0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] New exceptions mechanism
From: zeev@zend.com (Zeev Suraski)

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