If the built-in error handler is used null is returned. So, you can't reset the handler by giving it the returned value of the first call. Quite surprising, indeed.
@Exakat You can set the error handler by calling set_error_handler(null). It will set the error handler to the default state - according to the docs at least...
@Exakatset_error_handler first param is nullable. So if the first call to it returns null (when default handler is in use) in the first snippet you'd call set_error_handler the second time with a null argument, which ends up set the default handler (according to docs).
The difference seems to be that they kind of work on a stack. set_error_handler adds to the stack and restore_Error_handler removes from the stack. But when one calls restore_ twice it seems to use an unintended error handler. At least that was my explanation based on the observation that suddenly an error handler was used that I thought I had "unset"...
@heiglandreas so the end result after both snippets is that "smth" will be the current error handler.
But the "history" is different, and so calling restore_error_handler again (without a previous call to set_error_handler) will have a different result. Which means the general rule to avoid unexpected results is don't call restore_error_handlerif you haven't calledset_error_handler` first :) @Exakat@bhhaskin
Yes! But also, to restore the previous error-handler! Do not reset it onto the stack but instead use "restore_error_handler"!
I might have to extend the docs to add those findings.
Most people think setting an error handler is a variable assignment and setting another handler will overwrite the current value. Whereas "resetting" it will reset it to it's original state (which most people do not want to do).
Add comment