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_PARSEThe reason i did not allow
E_ERRORis 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 reallyE_ERRORand
that would be another BC issuue since it would also affect non exception code.
OR we convert the new error code into its originalE_ERRORcode before spitting
it out as a normal error.marcus
--
--------------------- Original Message Ends
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=1Maxim Maletsky
maxim@php.netOn 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_PARSEThe reason i did not allow
E_ERRORis 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 reallyE_ERRORand
that would be another BC issuue since it would also affect non exception code.
OR we convert the new error code into its originalE_ERRORcode before spitting
it out as a normal error.marcus
--
--------------------- Original Message Ends --------------------
--
--
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~