Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12781
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Mon, 13 Sep 2004 14:42:19 -0700
To: Sara Golemon <pollita@php.net>
Cc: internals@lists.php.net
Message-ID: <20040913214219.GA32049@gravitonic.com>
References: <20040909183405.63450.qmail@pb1.pair.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040909183405.63450.qmail@pb1.pair.com>
User-Agent: Mutt/1.4.1i
Subject: Re: [PHP-DEV] PHP's error handler: xmlrpc_errors, entity encoding, and handler chaining
From: andrei@gravitonic.com (Andrei Zmievski)

On Thu, 09 Sep 2004, Sara Golemon wrote:
> One last thing:  error handlers can be pushed/popped on and off of a stack
> using set_error_handler() and restore_error_handler(), and that's fine, but
> with the recent addition of the ability to fallback on the default error
> handler by returning an explicit FALSE from a user error handler, it may
> seem non-intuitive to the end user that this feature flows ALL the way back
> to the internal handler (skipping any prior handlers sitting on the stack),
> while restore_error_handler() operates by restoring merely the most recent
> handler.  Personally I'd like to see this follow the stack rather than jump
> all the way back.

Sara,

We have no error stack; not as such anyway. We are not talking about
exceptions here, just simple error handlers. People define the current
handler via set_error_handler() and that's all that's in effect until
they restore_error_handler() or set another one. There is no propagation
and I don't think there should be any.

- Andrei