> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
