Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:1493
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: Maxim Maletsky <maxim@php.net>
Cc: internals@lists.php.net
In-Reply-To: <20030513223357.6A42.MAXIM@php.net>
References: <20030513223357.6A42.MAXIM@php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Date: 13 May 2003 17:25:50 -0400
Message-ID: <1052861150.23340.9.camel@coogle.localdomain>
Mime-Version: 1.0
Subject: Re: [PHP-DEV] exceptions instead of errors
From: john@coggeshall.org (John Coggeshall)



> Just to throw some fuel into the fire: I still fancy the idea discussed m=
onths
> 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

=20
> here is some of that:
> http://groups.google.com/groups?q=3Dmaxim+%2Berror+group:php.dev&hl=3Den&=
lr=3D&ie=3DUTF-8&oe=3DUTF-8&group=3Dphp.dev&selm=3D20021121143311.63B5.MAXI=
M%40php.net&rnum=3D3
> http://groups.google.com/groups?q=3Dmaxim+%2Berror+group:php.dev&hl=3Den&=
lr=3D&ie=3DUTF-8&oe=3DUTF-8&group=3Dphp.dev&selm=3D000401c29448%2473f3f840%=
249d10fea9%40coogle&rnum=3D1
>=20
>=20
> Maxim Maletsky
> maxim@php.net
>=20
>=20
>=20
>=20
> On Tue, 13 May 2003 21:28:26 +0200
> marcus.boerger@t-online.de (Marcus B=C3=B6rger) wrote:
>=20
> > At 18:45 13.05.2003, Zeev Suraski wrote:
> > >Unless I'm missing something Marcus' patch only deals with non fatal=20
> > >errors.  But if I am missing something and it somehow tries to be smar=
t=20
> > >about E_ERRORs - it shouldn't, whether or not an error is fatal should=
 be=20
> > >left entirely to the author of the error call...
> >=20
> > 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
> >=20
> > The reason i did not allow E_ERROR is the fact that i knew some few err=
ors
> > which leave an unstable engine state.
> >=20
> > So perhaps a new error code isn't such a bad idea as i first thought. B=
ut=20
> > it makes
> > only sense when we change some codes which are aren't really E_ERROR an=
d
> > that would be another BC issuue since it would also affect non exceptio=
n code.
> > OR we convert the new error code into its original E_ERROR code before =
spitting
> > it out as a normal error.
> >=20
> > marcus
> >=20
> >=20
> > --=20
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >=20
>=20
>=20
> --------------------- Original Message Ends --------------------
>=20
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20
--=20
-~=3D~--~=3D~--~=3D~--~=3D~--~=3D~--~=3D~--~=3D~--~=3D~--~=3D~--~=3D~--~=3D=
~--~=3D~--~=3D~--~=3D~-
John Coggeshall
john at coggeshall dot org                 http://www.coggeshall.org/
-~=3D~--~=3D~--~=3D~--~=3D~--~=3D~--~=3D~--~=3D~--~=3D~--~=3D~--~=3D~--~=3D=
~--~=3D~--~=3D~--~=3D~-