Re: Re: [RFC] Autoloader Error Handling

On 11/25/2011 04:21 AM, Sebastian Krebs wrote:

2011/11/25 Ferenc Kovacs<tyra3l@gmail.com>

The problem with fatal, that you have no way (by the standard means, but you can somehow manage it through the usage of output buffers or register_shutdown_function, but thats ugly, and can change in the future) to intercept and gracefully terminate your application, which is an often needed feature. AFAIK E_FATAL should be only used where the engine is left in an unstable state, which isn't really true here.

Trying to interact with a non-existing class is not an unstable state? there are two situations: 1. The application is broken, thus the FATAL is appropriate 2. The application tries to work with dynamic class names. If it doesn't use class_exists() before, its broken and FATAL is appropriate So I think that E_RECOVERABLE_ERROR would be more appropriate here, and in

There's a third possibility. 3) The application uses a mapped or indexed autoloader and the map is out of date. Rebuilding the map would resolve the error. So I could see a use for a recovery there; if new NonExistentClass fails, try to rebuild the index and try again before fataling out entirely. Whether that's too much of an edge case or not, I don't know, but it is a legitimate use case. (Drupal 7 has an indexed autoloader, and we've run into the stale index problem many times. We're trying to migrate most code to PSR-0 for Drupal 8, but even that could use an index for caching/performance reasons.) --Larry Garfield