Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12782
Return-Path: <pollita@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 91722 invoked by uid 1010); 13 Sep 2004 23:03:07 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 83620 invoked by uid 1007); 13 Sep 2004 23:02:09 -0000
Message-ID: <20040913230209.83608.qmail@pb1.pair.com>
To: internals@lists.php.net
References: <20040909183405.63450.qmail@pb1.pair.com> <20040913214219.GA32049@gravitonic.com>
Date: Mon, 13 Sep 2004 16:02:07 -0700
Lines: 40
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Posted-By: 169.229.135.175
Subject: Re: [PHP-DEV] PHP's error handler: xmlrpc_errors, entity encoding, and handler chaining
From: pollita@php.net ("Sara Golemon")

> 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.
>
The stack I'm referring to isn't an error stack.  I mean the error HANDLERS
stack which gets pushed onto when a second error handler is set via
set_error_handler(), or popped off of via restore_error_handler() (when more
than one have been defined).

Zend/zend_globals.h
struct _zend_executor_globals {
...
    zend_stack user_error_handlers_error_reporting;
    zend_ptr_stack user_error_handlers;
...
};

Beyond the new "return false;" syntax, this also has implications for
scenarios like the following:

<?php
  set_error_handler('fatal_error_handler', E_USER_ERROR);
  set_error_handler('non_fatal_error_handler', E_ALL & ~E_USER_ERROR);
?>

Based on documentation one might expect E_USER_ERRORs to go to
fatal_error_handler(), and all others (since the rest of the fatal errors go
to the internal handler anyway) to go to non_fatal_error_handler().   The
reality of course, is that E_USER_ERRORs don't go anywhere near
fatal_error_handler(), they just get shuffled off to the internal handler.

So not only does itterating through the handlers stack give us a chaining
effect through "return false;" it also has the side-effect of letting the
script define handlers on a per error code basis.

-Sara