Re: set_error_handler() not handling E_ERROR

At 08:14 14/1/2001, Chris Newbill wrote:

Skimming the Zend code... Calls to undefined functions, class methods, and the like. What would be the cons of having these type of errors simply causing E_USER_ERROR instead of E_ERROR? That way they would be trapable and I don't think it would cause a problem if the user does not have a custom error handler. Changed the zend_execute.c file to E_USER_ERROR on undefined functions and method calls on non-object, PHP works fine and doesn't core.

That's an empyric (sp?) experiment, it doesn't necessarily mean that it's ok... As Rasmus said, we discussed this issue lately. We agreed that errors that can't be handled automatically (fatal errors), but don't leave the scripting engine in an unstable state, should be allowed to be handled by users. The example there was also calls to undefined functions. Unfortunately, calls to undefined functions do (or may) leave the engine in an unstable state, as far as I recall. I didn't get to review the code since then - so it may or may not be safe to let users trap this error. At any rate, we won't use E_USER_ERROR for this type of fatal, yet recoverable errors - but a new error level (E_TRAPPABLE_ERROR or something like that). Zeev -- Zeev Suraski <zeev@zend.com> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/