Re: exceptions instead of errors

Just to throw some fuel into the fire: I still fancy the idea discussed months ago about a new error reporting logic that would have some sort of unique codes for errors supported by strings. Something comparable to the way Oracle, C# and 'others' handles them. here is some of that: http://groups.google.com/groups?q=maxim+%2Berror+group:php.dev&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=php.dev&selm=20021121143311.63B5.MAXIM%40php.net&rnum=3 http://groups.google.com/groups?q=maxim+%2Berror+group:php.dev&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=php.dev&selm=000401c29448%2473f3f840%249d10fea9%40coogle&rnum=1 Maxim Maletsky maxim@php.net On Tue, 13 May 2003 21:28:26 +0200 marcus.boerger@t-online.de (Marcus Börger) wrote: > At 18:45 13.05.2003, Zeev Suraski wrote: > >Unless I'm missing something Marcus' patch only deals with non fatal > >errors. But if I am missing something and it somehow tries to be smart > >about E_ERRORs - it shouldn't, whether or not an error is fatal should be > >left entirely to the author of the error call... > > Atm the following error cannot be turned into an exception, all others can be. > E_ERROR > E_CORE_ERROR > E_COMPILE_ERROR > E_USER_ERROR > E_PARSE > > The reason i did not allow E_ERROR is the fact that i knew some few errors > which leave an unstable engine state. > > So perhaps a new error code isn't such a bad idea as i first thought. But > it makes > only sense when we change some codes which are aren't really E_ERROR and > that would be another BC issuue since it would also affect non exception code. > OR we convert the new error code into its original E_ERROR code before spitting > it out as a normal error. > > marcus > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > --------------------- Original Message Ends --------------------