On 11/25/2011 04:21 AM, Sebastian Krebs wrote:
2011/11/25 Ferenc Kovacs<tyr...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
