From: "Zeev Suraski" <[EMAIL PROTECTED]>
> 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
> >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

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
> 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
> 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

PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to