ID: 41648 Updated by: [EMAIL PROTECTED] Reported By: e dot a dot m dot huijbers at student dot tue dot nl -Status: Open +Status: Bogus Bug Type: Feature/Change Request PHP Version: 5.2.3 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 Test your code and use defensive coding techniques as in using is_object here. Fatal errors also cannot be caught and passed to user code in any way, that's why they are fatal. Previous Comments: ------------------------------------------------------------------------ [2007-06-11 10:24:20] e dot a dot m dot huijbers at student dot tue dot nl Description: ------------ This bug report is in response to BUG#40014 (among others), wherein it was said that uncatchable non-object/undefined function errors would not be turned into exceptions, because that would require engine rewrites. That bug has been closed, otherwise I would have posted there. I think I have a solution that can be implemented without too much trouble, increasing PHP's robustness in the area of exception handling. (Why I would like this fixed; we're running a large system with a lot of plug-ins. It's very frustrating that a simple error in one of the plug-ins, like this: --- $object = functionThatUsuallyReturnsAnObjectButNotThisTime(); $object->doSomething(); --- Brings the *whole system* down, even when we surround calls to plugins with try/catch blocks). To turn these errors into exceptions would allow them to be caught, thereby affecting now the whole system, but just the plug-in itself. All the tools to do this are trivially available. Solution: --- if (!is_object($object)) throw new Exception("Not an object"); $object->doSomething(); --- The solution is quite easy, and works! However, having to write this code for all thousands of method calls in any given production system is very cumbersome to say the least, and would make PHP a very unattractive language to use. IMO, the PHP parser should emit code, equivalent to the above, on every method call. If it did that, such "irrecoverable errors" would, in fact, become recoverable, without requiring extra work on the part of the user, and without changing any of the semantics of the involved constructs (the method call). The only extra work is a trivial modification of the parser/bytecode emitter, but it would make writing large-scale systems a lot more reliable and attractive. For the people worried about performance, because there always are: I would argue that the runtime of a typical PHP application is not dominated by function calls, but by I/O operations (to the database, over the wire, ...). In case where the extra check would notable affect performance (i.e., in tight inner loops) an alternative call syntax might be provided, that foregoes the extra is_object() check. This still keeps all modifications in the parser. Note the change it will never influence correctness, and increase reliability. One might argue that these properties are far more important than performance. For example, something like this could be introduced: --- $object->doSomething(); /* With safety check */ $object-^doSomething(); /* Without safety check */ /* This is not proposed syntax, just an example. The real decision is of course up to the language designers. */ --- (And please, please, do not tell me "this is not a bug". I have a lot of respect for the people that design PHP, but the current behaviour leaves a whole lot to be desired, and I highly doubt one could argue that the current behaviour is intended. It is an artifact of some underlying technical issues, sure, but that does not make it correct behaviour.) ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=41648&edit=1
