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 > general we use E_ERROR many places where E_RECOVERABLE_ERROR would be more > suitable, but thats another topic. > > For clarification: I'm talking about the E_FATAL which currently will be > called if none of the registered autoloaders were able to load the > requested class. > > On Fri, Nov 25, 2011 at 9:56 AM, Sebastian Krebs <krebs....@googlemail.com > > wrote: > >> Hi, >> >> Just to throw my 2 cent in: Im with Micheal. An application, that tries to >> access a class, that doesn't exists, is broken and a FATAL is valid. This >> application doesn't need try-catch, but a bugfix (and if it is already >> released: A better testing management). >> On the other side an application, that makes use of dynamic class names >> should make use of class_exists() in any case. An exception after calling >> class_exists() is just bad, but the classloader cannot distinguish between >> the reasons, why it is called. >> >> 2011/11/25 Christian Kaps <christian.k...@mohiva.com> >> >> > Am 25.11.2011 08:24, schrieb Michael Wallner: >> > >> > On Thu, 24 Nov 2011 23:28:35 +0100, Christian Kaps wrote: >> >> >> >> >> >>> https://wiki.php.net/rfc/**autoloader_error_handling< >> https://wiki.php.net/rfc/autoloader_error_handling> >> >> >>> >> >>> >> >> Throwing an exception or fatal error in an autoloader >> >> absolutely does not make any sense in my eyes. >> >> Projects doing this should step back and think a >> >> minute about what they dare. >> >> >> >> Mike >> >> >> > >> > Hi, >> > >> > how would you bring your application in a consistent state after a class >> > couldn't be loaded. I do this by adding a try/catch block around my >> code. >> > >> > try { >> > new Application(); >> > } catch (Exception) { >> > // collect data >> > // send mail >> > // redirect to maintenance page >> > } >> > >> > An other question is, if the autoloader work silent and I write: >> > >> > new NotExistingClass(); >> > >> > I think in this case the engine will also trigger a fatal error. So in >> my >> > eyes it is regardless of whether it trigger a fatal error in the >> autoloader >> > or the autoloader works silent. Both cases ends in a fatal error. Or am >> i >> > wrong here? >> > >> > Christian >> > >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> > >> > > > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu >
