Edit report at https://bugs.php.net/bug.php?id=52339&edit=1
ID: 52339
Comment by: ciantic at oksidi dot com
Reported by: dangerous dot ben at gmail dot com
Summary: SPL autoloader breaks class_exists()
Status: Re-Opened
Type: Bug
Package: SPL related
Operating System: any (debian)
PHP Version: 5.3.3RC2
Block user comment: N
Private report: N
New Comment:
Is this bug still happening in PHP5.4 and greater? I'm using 5.3.8.
If one uses class_exists it should never throw error, only true or false. It
makes
no sense otherwise. This is one of those where setting of some other
application
can totally broke functionality elsewhere. Should everyone using class_exists
catch try LogicException too? I'd argue not.
Though the workaround (empty function for spl) is kind of nice, as dangerous
dot
ben mentioned.
Previous Comments:
------------------------------------------------------------------------
[2012-08-08 16:18:39] kilbyc at bellsouth dot net
Even worse. The no arg register is inconsistent.
<?php
print_r(class_exists('asdfasdf'));//no error, just false.
spl_autoload_register();
print_r(class_exists('asdfasdf'));//LogicException
?>
<?php
print_r(class_exists('asdfasdf'));//no error, just false.
spl_autoload_register('spl_autoload');
spl_autoload_unregister('spl_autoload');
spl_autoload_register();
print_r(class_exists('asdfasdf'));//no error, just false.
?>
If the autoload stack is empty by the time the no arg registered is called, how
can it function differently than if the autoload stack has been emptied by the
time the no arg register is called?
This is nonsensical behavior, and manual for spl_autoload say nothing about it
throwing. Let alone LogicException. I would have expected this to be a
RuntimeException. As it depends on the specific environment it is run in as to
whether or not spl_autoload will find something.
------------------------------------------------------------------------
[2012-08-08 16:02:40] kilbyc at bellsouth dot net
PHP 5.3.8 (cli) (built: Aug 23 2011 11:50:20)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
<?php
print_r(class_exists('asdfasdf'));//no error, just false
spl_autoload_register();
print_r(class_exists('asdfasdf'));//LogicException.
?>
<?php
class_exists('asdfasdf');//no error, just false.
spl_autoload_register('spl_autoload');
class_exists('asdfasdf');//no error, just false.
?>
spl_autoload is inconsistent with itself.
------------------------------------------------------------------------
[2012-03-16 22:02:29] pwolfenden at qualys dot com
Although I have not yet migrated to 5.3, I care about this bug because I'm
using
an autoload function (in 5.2) which contains some directory traversal logic and
uses class_exists() to decide whether or not to keep looking. I need to do this
because I'm in the scenario described by james (and so cannot assume that all
the
package files in my codebase follow my preferred naming convention), and I
would
much prefer class_exists() to continue to return false rather than having it
throw
a new Exception.
------------------------------------------------------------------------
[2012-02-03 00:01:46] frozenf...@php.net
Re-opening, as there still exists the conflict of class_exists() generating an
error when autoloading fails, which is a chicken and the egg sort of issue. If
one wants to try autoloading if the class doesn't exist, but autoloading fails,
it should be possible to recover from that failure.
My understanding of the underlying code is that it generates an error in this
case. Perhaps it should generate an exception, which can be caught an handled.
------------------------------------------------------------------------
[2010-10-11 21:37:47] james at nearlysensical dot com
I 100% agree with dangerous dot ben. class_exists should return false if the
class
can't be autoloaded. Allowing it to do so would make it much easier to use an
autoloader in contexts where you're interacting with an existing codebase that
may
not be so spl_autoload friendly. Bump.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=52339
--
Edit this bug report at https://bugs.php.net/bug.php?id=52339&edit=1
