Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.5.0
-
Fix Version/s: 1.8.0
-
Component/s: Zend_Loader
-
Labels:None
Description
Autoload functions should not cause errors when they can't include the requested class. They may only be one function in the autoload stack, or they may be being used by class_exists() to simply check if a class is available. It isn't the job of any individual autoload to ensure a class is defined, therefore they should fail silently in the event that they cannot include the class.
At present the Zend_Loader::loadClass() method (used by Zend_Loader::autoload()) causes a PHP file not found warning if it cannot include the requested class. (Line 83)
Issue Links
| This issue is duplicated by: | ||||
| ZF-2996 | ZF 1.5.0 breaks co-existance with external libs (domPDF) |
|
|
|
| This issue is related to: | ||||
| ZF-2463 | Zend_Loader suppressing parse errors when loading class files |
|
|
|
| This issue is related to: | ||||
| ZF-2724 | Error supression on calls to loadClass across ZF obscuring parse errors |
|
|
|
| ZF-2701 | Zend_Loader::isReadable triggers E_WARNING with user defined helper paths |
|
|
|
| ZF-2924 | Silent failures caused by @Zend_Loader::loadClass() |
|
|
|
One obvious solution is to change the autoload() method to suppress errors on the call to self::loadClass(), but what happens when the file does exist, and it has a parse error or a warning that the developer should see? Such error suppression solves one problem while causing other potential problems. The complexity of dealing with PHP errors here is a bit like a waterbed... if you push down one side, the other side pops up.
The next step would be to capture the errors and make them available to the calling script (except fatal errors of course), but this may be a performance hog. We'll need some tests and benchmarks, I think.
Maybe someone else has a better idea?