rfc:autoloader_error_handling
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:autoloader_error_handling [2011/11/16 22:05] – 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 < | ||
- | * Status: Draft | ||
- | * First Published at: https:// | ||
- | |||
- | ===== Terms ===== | ||
- | |||
- | I use the following terms in the subsequent examples: | ||
- | * project - for every piece of software(library, | ||
- | * 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' | ||
- | * 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' | ||
- | |||
- | ===== Introduction ===== | ||
- | |||
- | If working in a multi project environment, | ||
- | |||
- | ===== Problems ===== | ||
- | Note: | ||
- | |||
- | | ||
- | * 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. | ||
- | |||
- | * 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 | ||
- | |||
- | This means, for example: | ||
- | 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 how the procedure continues. | ||
- | |||
- | * For the main project it should be possible to manipulate the behavior of an autoloader | ||
- | |||
- | This means, for example: | ||
- | 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. | ||
- | |||
- | |||
- | |||
- | ===== Changelog ===== | ||
- | |||
- | 0.1 - First draft | ||