Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:7593
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Wed, 4 Feb 2004 23:29:59 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <70-447866953.20040204232959@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.20040203143932.0733a0d0@localhost>
References: <5.1.0.14.2.20040203143932.0733a0d0@localhost>
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,

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