On Sun, Jul 5, 2009 at 8:49 PM, Ben Bidner <b...@vuetec.com> wrote:
> 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
