ID: 33355 Updated by: [EMAIL PROTECTED] Reported By: jr at terragate dot net -Status: Assigned +Status: Bogus Bug Type: SPL related -Operating System: Mac OS X 10.4.1 +Operating System: * PHP Version: 5CVS-2005-06-15 (dev) Assigned To: helly New Comment:
Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php In this case i don't see any motivation to change since you shouldn't be using is_a() anyway. However the point is that unfortunatley some php internal api's do not support detailed error informations. In fact no php internal code can deliver detailed exceptions with the exception being a few xml and spl classes. Thus it is not a problem of SPL which here only makes use of other api's. The reason SPL now needs to throw on warnings is that some of the warnings mean that the object cannot be initialized thus being in an invalid state so that it needs to be assuered that the constructor fails so that the object cannot be used. Since i cannot distunguish the cause of the error i am forced to throw on any error. Actually i could limit it to E_WARNING but then again i'd need to change a lot of php internal things. Previous Comments: ------------------------------------------------------------------------ [2005-06-15 17:14:00] jr at terragate dot net Description: ------------ Currently SPL sets the error_handling to EH_THROW which will cause any E_WARNING or E_STRICT message to be thrown as exception regardless of error_reporting's settings. This renders most code with compatibility in mind (e.g. PEAR) useless in SPL context since there is no way to ignore non fatal warnings. At least E_STRICT messages shouldn't be thrown if it is disabled in error_reporting. But this might still be confusing. E_STRICT massages should be treated as compile time warnings (as in most other languages). They shouln't affect the control flow if not explicitly requested. Generally the same applies to E_WARNING and E_USER_WARNING as long as there is no way to disable EH_THROW in user space php code. IMHO EH_THROW should be completly disabled or the error mode should be made controlable: // ignore warnings from this wrapper error_mode(EH_NORMAL); $it = new DirectoryIterator('legacywrapper://path/'); // I want to stop on some warnings error_mode(EH_THROW); try { $it = new DirectoryIterator('legacywrapper://path/'); } catch(Exception $e) { // parse exception which might contain an E_WARNING message // this is not really OO but it works ... if($criticalWarning) { // bail out throw new AMoreAppropriateException(); } else { // non critical warning trying again with EH_NORMAL // using normal php error/warning handling here ... } } As long as all warnings are thrown as 'Exception' the EH_THROW mode can't be used as different warnings cannot be easily distinguished. Reproduce code: --------------- <?php error_reporting(E_ALL & ~E_NOTICE & ~E_STRICT); class StreamWrapper { public function dir_opendir($path, $options) { return !is_a(null, 'AKnownOrUnknownClass'); } public function dir_readdir() { return array(); } } stream_wrapper_register('test', 'StreamWrapper'); echo "Done\n"; ?> Expected result: ---------------- Output of "Done" Actual result: -------------- Fatal error: Uncaught exception 'Exception' with message 'is_a (): Deprecated. Please use the instanceof operator' in /Users/ reith2/Projects/php/bug-new.php:8 Stack trace: #0 /Users/reith2/Projects/php/bug-new.php(8): is_a(NULL, 'AKnownOrUnknown...') #1 /Users/reith2/Projects/php/bug-new.php(18): StreamWrapper- >dir_opendir('test://path/', 4) #2 /Users/reith2/Projects/php/bug-new.php(18): DirectoryIterator->__construct('test://path/') #3 {main} ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=33355&edit=1
