Generally speaking, many users want to be able to catch every error possible. If there is an error condition that happens, they want to be able to catch it.
If it's not possible to catch it in script, perhaps an extension or some other strategy needs to be documented for certain error conditions. Anyone who develops systems with 99.99 or 99.999% availability (~5 minutes downtime per year) needs to account for all error conditions, and this is required in things like telephone systems, military systems, etc. Hey, you may want a web interface to those systems ;) Regards, Al On Tue, 2005-08-23 at 16:12 -0700, Andi Gutmans wrote: > Hi Derick, > > 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? > > Andi > > At 05:15 AM 8/23/2005, Derick Rethans wrote: > >On Mon, 22 Aug 2005, George Schlossnagle wrote: > > > > > E_FATAL > > > > > > Leaving current errors as E_ERROR (since most are recoverable, imho) > > > >I have a patch for this ready. In most of the engine I converted all > >E_ERRORs to E_FATALs (except the type hints), and in most of the > >extensions I kept the E_ERRORs in case there is proper error handling > >for cases where an E_ERROR would not have aborted. Major exceptions here > >are ext/hwapi, ext/soap, ext/simplexml and ext/ming. These need to be > >fixed. In some cases I added RETURN_FALSE or return. > > > >I also updated some test cases. You can find the patch here: > >http://files.derickrethans.nl/e_fatal-20050823.diff.txt > > > >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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
