Bug #76980 [Opn->Ver]: Interface gets skipped if autoloader throws an exception

From: Date: Tue, 09 Oct 2018 12:13:51 +0000
Subject: Bug #76980 [Opn->Ver]: Interface gets skipped if autoloader throws an exception
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-217482@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=76980&edit=1

 ID:                 76980
 Updated by:         cmb@php.net
 Reported by:        martin at auswoeger dot com
 Summary:            Interface gets skipped if autoloader throws an
                     exception
-Status:             Open
+Status:             Verified
 Type:               Bug
-Package:            *General Issues
+Package:            Scripting Engine problem
 PHP Version:        7.2.10
 Block user comment: N
 Private report:     N

 New Comment:

For reference: <https://3v4l.org/s8ti7>


Previous Comments:
------------------------------------------------------------------------
[2018-10-07 01:28:09] a at b dot c dot de

Allowing the creation of class Foo to go ahead even if its interface failed to autoload would also
bite users who use type declarations in function signatures.

<?php
function dowithfoo(Foointerface $foo)
{
	return;
}

dowithfoo(new Foo());
?>

------------------------------------------------------------------------
[2018-10-06 22:24:14] martin at auswoeger dot com

A partial loaded class is very confusing I think. Most developers probably wouldn’t expect that
a class can be loaded without its interfaces.

> What's the expected *behavior* here?

If you change the above test script from implements to extends it behaves
as I would expect it.

There is also a Symfony bug report that shows a real world use case where this behavior was
unexpected and causes issues: <https://github.com/symfony/symfony/issues/28748>

------------------------------------------------------------------------
[2018-10-06 22:17:27] nikic@php.net

> What's the expected *behavior* here? That Foo should not be defined at all since the
> interface couldn't be loaded?

Yes, that would be the expected behavior.

Master has some changes that should make it easier to correctly handle this. Right now the code
segfaults though.

------------------------------------------------------------------------
[2018-10-06 21:56:20] requinix@php.net

What's the expected *behavior* here? That Foo should not be defined at all since the interface
couldn't be loaded? And the second "load" of Foo trigger the autoloader again and
raise the exception again?
I think the way it works now is fine: Foo could be mostly defined except the interface, there was no
other problem with it, and PHP was quite happy to raise an exception which you totally ignored. At
least this way the code has a chance of working.

Or what if the exception was actually an Error? It's semantics, but that way you wouldn't
accidentally catch it.

------------------------------------------------------------------------
[2018-10-06 21:38:23] martin at auswoeger dot com

Description:
------------
If a class implements an interface for which the registered autoloader throws an exception, the
class is actually defined afterwards but without the interface.

Test script:
---------------
<?php

spl_autoload_register(function ($class) {
    if ('Foo' === $class) {
        class Foo implements Foointerface {}
    } elseif ('Foointerface' === $class) {
        throw new Exception();
    }
});

try {
    // First call triggers the autoloader
    new Foo();
} catch (Exception $e) {}

// For the second call Foo is loaded
var_dump(new Foo());

// Even though it’s missing the interface
var_dump(new Foo() instanceof Foointerface);
var_dump((new ReflectionClass('Foo'))->getInterfaces());

Expected result:
----------------
Fatal error: Uncaught Exception in …  
thrown in … on line 7

Actual result:
--------------
object(Foo)#3 (0) {
}
bool(false)
array(0) {
}


------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=76980&edit=1


Thread (10 messages)

« previous php.bugs (#217482) next »