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.
> 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 serio
> 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
On Thu, 09 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 ex
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 exp
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 htmlspecialch
