autoloading and undefined class constants View as Markdown

Hi folks,

Just looking for a quick clarification on how class constant look ups are
performed internally under circumstances when an autoload function is also
called.

Consider the following example:

<?php

function autoloader($className)
{
throw new Exception("Fail");
}

spl_autoload_register("autoloader");

?>

<?php

// Exception
$obj = new NonExistantClass;

?>

<?php

// Fatal error
$const = NonExistantClass::NON_EXISTANT_CONSTANT;

?>

I would have assumed that since the autoloader threw an exception while
attempting to load the non existant class, that internally, there would be
no attempt to access the non existant constant (since surely that comes
after the exception was thrown???) and we would get the Exception, rather
than a Fatal error.

Intended or a design error?

per the manual, exceptions thrown in an autoload method are swallowed, and
an E_ERROR is triggered by php.

http://us2.php.net/manual/en/language.oop5.autoload.php

personally, i dont know why it works this way.. even if you register an
error handler, you cant handle it from user-space, b/c set_error_handler()
only lets you handle E_USER_ERROR.. there are 2 issues this presents,

1. if your autoloading logic creates a message that it would pass through to
   higher level code, via exceptions or errors, they are swallowed, so you dont
   know what went wrong.
2. if you call die() you can log the message, however youll not be able to
   leverage standard error handling code here, at least not via a thrown
   exception or triggered error

the only solution ive found is to invoke the standard error handling code
directly from the autoloading logic.

imo, this defeats the purpose of the loose coupling errors and exceptions
provide. one of the reasons its really painful is because the autoloader is
startup code.., which means you cant leverage it to load its dependecies,
which means your error logging code cant leverage the autoloading logic iff
the autoloading logic has to call the error handling logic directly:( when
i say 'standard error handling logic' i mean like loading up a static html
page, or similar.

i think, since failures in autoload result in an E_ERROR, it would at least
make sense to allow user-space to trigger E_USER_ERROR, which PHP could
allow to pass through the autoload method untouched. i think this is
reasonable, b/c E_USER_ERROR still interrupts program execution, and then
userspace could leverage the same error handling code it does for everything
else when problems occur with autoloading.

id seen some posts on php.net about using output buffering to be able to
trap E_ERROR but then came to discover that output buffering has been
disabled on the cli since like 4.3.5, so the example code like,

<?php
ob_start();
call_fake_function();
?>

would blow up w/ a fatal on all my installations. id post on php-general
about it, but im more curious to see what internals folks think about it.

-nathan

<?php

  function autoloader($className)
  {
     throw new Exception("Fail");
  }

  spl_autoload_register("autoloader");

The whole point of spl_autoload_register() is to allow programmers to
have several independent autoloaders. So, it is a bad practice to
throw exception from autoload — doing so, you forbid system to try the
next autoloader.

Good practice is: if you can't load class from autoloader — just
silently return from it

--
Alexey Zakhlestin
http://www.milkfarmsoft.com/