Going through some error handling code, I noticed that while Plaintext and
HTML errors use the error_prepend_string and error_append_string php.ini
directives in the construction of their error messages, XML errors do not.
Any particular reason for that?
I also notice that there's no htmlspecialchars() type treatment for the
error strings when used in HTML or XML mode. Not exactly the most common
route for an XSS attack, and probably not one worth worrying about, but it
seems lacking.
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
One last thing: error handlers can be pushed/popped on and off of a stack
usingset_error_handler()andrestore_error_handler(), and that's fine, but
with the recent addition of the ability to fallback on the default error
handler by returning an explicitFALSEfrom 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),
whilerestore_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
Having it trickle back through the stack would make sense to me too.
http://pecl.org/sara/error_chaining.diff
Here's the basic idea of what I had in mind.
This patch is actually not the way I'd like to see it implemented, but
rather the most expedient demonstration as it doesn't involve seriously
changing the way error handlers are registered and stored. And anyway, it's
functional.
-Sara
Personally I prefer today's approach vs. a more complex chaining solution.
It only requires an additional if() in your error handler to handle
different error codes differently.
At 10:07 PM 9/13/2004 -0700, Sara Golemon wrote:
Having it trickle back through the stack would make sense to me too.
http://pecl.org/sara/error_chaining.diff
Here's the basic idea of what I had in mind.
This patch is actually not the way I'd like to see it implemented, but
rather the most expedient demonstration as it doesn't involve seriously
changing the way error handlers are registered and stored. And anyway, it's
functional.-Sara
One last thing: error handlers can be pushed/popped on and off of a stack
usingset_error_handler()andrestore_error_handler(), and that's fine, but
with the recent addition of the ability to fallback on the default error
handler by returning an explicitFALSEfrom 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),
whilerestore_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
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 viaset_error_handler()and that's all that's in effect until
theyrestore_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