Re: exceptions instead of errors

php.internals

Maxim Maletsky

23 years ago
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 --------------------

John Coggeshall

23 years ago
> 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.
Lol. I'm not touching that topic again ;) Besides, if something gets hashed out where the engine can start throwing exceptions internally the benefits from "[PHP-34234]" as an error code is reduced. John
> 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 -------------------- > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
-- -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~- John Coggeshall john at coggeshall dot org http://www.coggeshall.org/ -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-