rfc:autoloader_error_handling
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:autoloader_error_handling [2011/11/20 11:41] – [Requirements] akkie | rfc:autoloader_error_handling [2011/11/20 12:15] – akkie | ||
---|---|---|---|
Line 10: | Line 10: | ||
I use the following terms in the subsequent examples: | I use the following terms in the subsequent examples: | ||
* project - for every piece of software(library, | * project - for every piece of software(library, | ||
- | * autoloader(Exception) - for an autoloader | + | * autoloader(Exception) - for an autoloader |
- | * autoloader(Error) - for an autoloader | + | * autoloader(Error) - for an autoloader |
- | * autoloader(Silent) - for an autoloader | + | * autoloader(Silent) - for an autoloader |
- | * policy(Exception) - for a policy | + | * policy(Exception) - for a policy |
- | * policy(Error) - for a policy | + | * policy(Error) - for a policy |
- | * policy(Silent) - for a policy | + | * policy(Silent) - for a policy |
===== Introduction ===== | ===== Introduction ===== | ||
- | If working in a multi project environment, | + | If working in a multi project environment, |
===== Problems ===== | ===== Problems ===== | ||
Line 31: | Line 31: | ||
**Examples: | **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. | + | * 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. | * 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. | * 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. | ||
Line 41: | Line 41: | ||
* Autoloaders may not interfere with each other | * 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 how the procedure continues. | + | * 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 | * 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. | * 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. | ||
+ | * On the other side it should be possible to manipulate an autoloader(Exception) or autoloader(Error), | ||
* Sub projects(libraries, | * Sub projects(libraries, | ||
- | * If I have defined an autoloader(Exception) in my sub project, then it must be guaranteed that I can catch exceptions thrown by this autoloader, in my sub project. Even if the main project changes the behavior of autoloader. | + | * If I have defined an autoloader(Exception) in my sub project, then it must be guaranteed that I can catch(in this sub project) |
+ | |||
+ | ===== Solution ===== | ||
+ | |||