Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:12691 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 39007 invoked by uid 1010); 9 Sep 2004 19:39:45 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 24229 invoked from network); 9 Sep 2004 19:34:51 -0000 Received: from unknown (HELO colo.lerdorf.com) (66.198.51.121) by pb1.pair.com with SMTP; 9 Sep 2004 19:34:51 -0000 Received: from [192.168.1.105] (c-24-6-200-247.client.comcast.net [24.6.200.247]) by colo.lerdorf.com (8.13.1/8.13.1/Debian-12) with ESMTP id i89JYo7h009582; Thu, 9 Sep 2004 12:34:50 -0700 Date: Thu, 9 Sep 2004 12:34:44 -0700 (PDT) X-X-Sender: rasmus@t42p.lerdorf.com To: Sara Golemon cc: internals@lists.php.net In-Reply-To: <20040909183405.63450.qmail@pb1.pair.com> Message-ID: References: <20040909183405.63450.qmail@pb1.pair.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] PHP's error handler: xmlrpc_errors, entity encoding, and handler chaining From: rasmus@php.net (Rasmus Lerdorf) On Thu, 9 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. Having it trickle back through the stack would make sense to me too. Andrei? -Rasmus