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.
As this is only for PHP 6, I dont see a real reason as if those extensions get updated for Unicode, things like returning ERRORs should be revised anyway. (In any case, people *should* go through their extension and check whether they still "conform" to our error guidelines). > 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 can change that, but IMO it's less elegant. What do others think? 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
