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
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
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
