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
>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
Zeev Suraski <[EMAIL PROTECTED]>
CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/
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]