On Wed, 24 Aug 2005, Zeev Suraski wrote: > At 09:26 24/08/2005, Derick Rethans wrote: > >On Tue, 23 Aug 2005, Andi Gutmans wrote: > > > > > I didn't quite understand. Users would be able to handle E_FATAL > > errors? How > > > would exceptions from those user handlers propagate the C extensions? > > > >No, they would only be able to catch E_ERROR, E_FATAL is the current > >"E_ERROR" and can NOT be caught by the user defined error handler. > > > >New status (or atleast, IMO): > >E_NOTICE: Just for little notices to inform the user that something > > might have gone wrong. > >E_WARNING: Something went wrong, probably resulting in unwanted > > behavior. > > No change here (good!) > > >E_ERROR: An error situation occurred, which is probably dangerous for > > a script to continue, but does not leave the Engine itself in > > an unstable state. If this one is not caught in a user > > defined error handler, the application aborts. > >E_FATAL: The engine is in an unstable state, we have to abort. Not > > catchable by a user defined error handler. > > Replacing the meaning of E_ERROR is elegant, but it does create a problem of > cross-version compatibility of extensions (at the source code level). If you > want to raise an error that terminates execution, you'll have to do it in two > different ways - that's quite annoying. While I think there are a lot of > situations where E_ERROR is an overkill, there are tons of situations where it > isn't, so this is an issue. > > Given that, I think we should go with the introduction of a new error level, > E_RECOVERABLE_ERROR, and keep E_ERROR with its existing meaning.
I implemented that (except I dropped the _ERROR part for E_RECOVERABLE_ERROR as I found it too long). The patch is here: http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt Any comments? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
