Re: [PHP-DEV] 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 [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]
Re: [PHP-DEV] set_error_handler() not handling E_ERROR
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]
Re: [PHP-DEV] set_error_handler() not handling E_ERROR
This was covered recently. See http://marc.theaimsgroup.com/?l=php-devm=97673386418430w=2 On Sat, 13 Jan 2001, Chris Newbill wrote: PHP Version 4.0.3pl1 and 4.0.4 It was my understanding that when using set_error_handler() ALL errors were sent to the users function? This does not seem to be happening. error.lib $oeh = set_error_handler("dosojin_ERROR"); error_reporting(E_ERROR | E_WARNING | E_PARSE | E_CORE_ERROR | E_COMPILE_ERROR | E_USER_ERROR | E_USER_WARNING | E_USER_NOTICE); tmp.php ? include("dosojin.lib"); // constants only include("error.lib");// error handling routines function foo($var) { print "Hello, $var!\n"; } foo(); $i = 1; $i-noFunc(); ? # php -q tmp.php PRE CLASS=error (2) Missing argument 1 for foo() /PRE Hello br bFatal error/b: Call to a member function on a non-object in btmp.php/b on line b14/bbr You can see that E_WARNING is getting shuffled to the user function, but E_ERROR is not. Thanks, 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] -- 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]