On Fri, Nov 25, 2011 at 11:21 AM, Sebastian Krebs <krebs....@googlemail.com>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? > "where the __engine__ is left in an unstable state" trying to interact with a non-existing class could push the __application__ in an unstable state, but changing E_ERROR to E_RECOVERABLE_ERROR would give a chance for those developers/applications to gracefully terminate. > there are two situations: > > 1. The application is broken, thus the FATAL is appropriate > so should we change all instance of E_NOTICE, E_WARNING and E_STRICT to E_ERROR? usually those also mean that the code is broken... > 2. The application tries to work with dynamic class names. If it doesn't > use class_exists() before, its broken and FATAL is appropriate > same here. I agree that trying to load an non-existing class is a bug, but E_ERROR is not a punishment for buggy code, it is a safety measure, when there is no safe way to give back the control to the application, because the engine for that request is beyond repair. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
