From: e dot a dot m dot huijbers at student dot tue dot nl
Operating system:
PHP version: 5.2.3
PHP Bug Type: Feature/Change Request
Bug description: Turning fatal non-object/undefined errors into exceptions
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 bug report at http://bugs.php.net/?id=41648&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41648&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41648&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41648&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41648&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41648&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41648&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=41648&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=41648&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41648&r=support
Expected behavior: http://bugs.php.net/fix.php?id=41648&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41648&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41648&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41648&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41648&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41648&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=41648&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41648&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41648&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41648&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=41648&r=mysqlcfg
