Request for Comments: Autoloader Error Handling

• Version: 0.1
• Date: 2011-11-14
• Author: Christian Kaps christian.kaps@mohiva.com
• Status: Draft
• First Published at: https://wiki.php.net/rfc/autoloader_error_handling

I use the following terms in the subsequent examples:

• application - for every piece of software(library, application, tool, ...)
• autoloader(Exception) - for an autoloader which throws an exception
• autoloader(Error) - for an autoloader which ends in a fatal error
• autoloader(Silent) - for an autoloader which doesn't throw any error
• policy(Exception) - for a policy which relies on exceptions
• policy(Error) - for a policy which relies on errors
• policy(Silent) - for a policy which doesn't allow any error

If working in a multi application environment, sooner or later it comes to incompatibility between the registered autoloader implementations. The problem is that one registered autoloader can throw an exception, an other one ends in a fatal error and a third doesn't throw any error. So we need a solution which can handle all these cases based on the policy of the application scope.

* If an application registers its own autoloader than it uses automatically the same policy. I won't attribute this in the examples.
* All autoloader implementations aren't compatible. They cannot load classes across projects.
* The notation autoloader(...)-1 describes the position of the loader in the stack. The first position in this example.

1. A third party library registers its own autoloader(Exception)-1. The application registers its own autoloader(silent)-2. In this case the autoloader of the application will never be executed and therefore it cannot load any application class. A workaround would be to register the application autoloader as first.
2. PHPUnit registers several autoloaders(Silent)2-10. The test suite uses an autoloader(Exception)-1. Same problem here. None of the PHPUnit classes can be loaded. A workaround would be to register the test suite autoloader as last.
3. A third party library registers its own autoloader(Exception)-1. The application registers its own autoloader(Error)-2. The same problem as in the first example. But here exists no workaround because the two autoloaders mutually interfere.
4. Every combination of non silent autoloaders shares the same problem as in the example before.

The consideration should be “how do I make it possible that any application can use its own autoloader implementation based on its own policy”. So the following requirements must be complied with.

1. Autoloaders must not interfere with each other

0.1 - First draft