Re: PHP's error handler: xmlrpc_errors, entity encoding, and handler chaining

> 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