Re: set_error_handler() not handling E_ERROR

From: "Zeev Suraski" <zeev@zend.com> > At 08:14 14/1/2001, Chris Newbill wrote: > >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... Yes, that is a spelling mistake, empiric is what you want I believe. =) (although I did have to look that word up it's almost 4am urgh) And yes I would agree, knowing exactly how a change like this would affect something as complex as the Zend engine is definately beyond my immediate understanding of how it works. > 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). Sounds good to me. Chris Newbill