Differences

This shows you the differences between two versions of the page.

--- rfc:autoloader_error_handling [2011/11/20 11:59] – [Requirements] akkie
+++ rfc:autoloader_error_handling [2013/12/23 13:44] (current) – removed akkie
@@ Line 1: / Line 1: @@
-====== 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
-===== Terms =====
-I use the following terms in the subsequent examples:
-  * project - for every piece of software(library, application, tool, ...)
-  * autoloader(Exception) - for an autoloader that throws an exception
-  * autoloader(Error) - for an autoloader that triggers a fatal error
-  * autoloader(Silent) - for an autoloader that behaves silent
-  * policy(Exception) - for a policy that relies on exceptions
-  * policy(Error) - for a policy that relies on errors
-  * policy(Silent) - for a policy that relies on a silent behavior
-===== Introduction =====
-If working in a multi project 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 triggers a fatal error and a third behaves silent. So we need a solution which can handle all these cases based on the policy of the project scope.
-===== Problems =====
-**Notes:**
-  * If an project 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.
-**Examples:**
-  * A third party project registers its own autoloader(Exception)-1. The main project registers its own autoloader(Silent)-2. In this case the autoloader of the main project will never be executed and therefore it cannot load any main project class. A workaround would be to register the main project autoloader as first.
-  * 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.
-  * A third party project registers its own autoloader(Exception)-1. The main project 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.
-  * Every combination of non silent autoloaders shares the same problem as in the example before.
-===== Requirements =====
-As a consequence of the the previous problems now we have the following requirements which have to be fulfilled to work error-free across multiple projects.
-  * Autoloaders may not interfere with each other
-     * If I have an autoloader(Error) in project A and an autoloader(Exception) in project B then both autoloaders must be processed. Only if both autoloaders fails to load the class, a decision should be made on how the autoloader mechanism behaves.
-  * For the main project it should be possible to manipulate the behavior of an autoloader
-     * If an autoloader(Silent) fails to load a class from a sub project, it should be possible to change the behavior of the autoloader to the effect that an exception will be thrown. This could be necessary to shutdown the application in an ordered way.
-  * Sub projects(libraries, frameworks, ...) must rely on their own policy
-     * If I have defined an autoloader(Exception) in my sub project, then it must be guaranteed that I can catch(in this sub project) exceptions thrown by this autoloader. Even if the main project changes the behavior of autoloader.
-===== Changelog =====
-.1 - First draft

Differences

Page Tools