Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62029
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <250022DBD6DE4F50BBAD1CB655909382@pc>
References: <CAH-PCH7874id459NTuMqL6pzL=feRtaWUAiPiSqPDa73tnFy9w@mail.gmail.com>
	<CAF+90c_R7D3OC5ubzOAw46E3hoPdeyOYD5H2vXU5Uy_CqirOVg@mail.gmail.com>
	<6214E40C106D49398CC920D8587815B4@pc>
	<CAH-PCH5A+0-7qw3ut-Sf_Ax9iZ4m-YFj25T_33UUrrDY2pUxDg@mail.gmail.com>
	<250022DBD6DE4F50BBAD1CB655909382@pc>
Date: Sat, 4 Aug 2012 02:22:10 +0200
Message-ID: <CAH-PCH6PNrCk8yrtgq8sGN=+Jk=z1Y6EEvLQRq+TEZfDkHJjHQ@mail.gmail.com>
To: Stan Vass <sv_forums@fmethod.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP Internals <internals@lists.php.net>, 
	Andrew Faulds <ajf@ajf.me>, Etienne Kneuss <colder@php.net>
Content-Type: multipart/alternative; boundary=f46d042f972cb8651e04c665a2c2
Subject: Re: [PHP-DEV] Error handling brainstorming
From: tyra3l@gmail.com (Ferenc Kovacs)

--f46d042f972cb8651e04c665a2c2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 4, 2012 at 1:44 AM, Stan Vass <sv_forums@fmethod.com> wrote:

> **
>
>
> On Sat, Aug 4, 2012 at 1:16 AM, Stan Vass <sv_forums@fmethod.com> wrote:
>
>> When I said I'd like to see E_STRICT be fatal/exceptions it wasn't a
>> typo. My choice isn't based as much on what the current error severity i=
s,
>> or what the error severity is supposed to represent in general, because
>> I've found in PHP often the error severity has no connection with the er=
ror
>> that's being reported. So I decided this by observing the real-world err=
ors
>> that use a certain severity.
>>
>> Many warnings and all E_STRICT errors clearly point to bugs in the code,
>> wrong method signatures, non-existing variables and constants being used=
,
>> which can easily do actual data damage if the script keeps running in
>> undefined state (even if the engine is just fine with it).
>>
>
> are you sure about that?
> E_STRICT is more about code that works but relying on some quirk or
> side-effect or simply does a stupid thing.
>
>
> Well think about it. Why is it a goal to let quirky/stide-effect/stupid
> code run? This almost always ends badly.
>
> It also reduces compatibility between code libraries. I.e.:
>

my words aren't getting through to you.



>
>  it is the opposite, we allowed sloppy code in the past, and introduced
> E_STRICT to allow the pedantic people to find and fix the quirks and
> E_DEPRECATED for finding and migrating the code which will go away.
>
>
> If you use a well tested, popular library by "sloppy" coders who don't
> mind E_STRICT and E_NOTICE, but you're "pedantic", what happens? You have
> to live with your error log filled with noise from the library or fork th=
e
> library.
>
> And when the "sloppy" coders miss bugs because they've decided the real
> PHP is about sloppy code that still works somehow, they miss bugs and the=
n
> blame themselves or PHP for being a language that allows buggy code.
>
> This is the end result if trying to turn PHP into everything for
> everybody. Instead, PHP should make up it's mind and stop littering the
> php.ini with semantics/behavior configuration for the language.
>
> Have one behavior. Stick with it. Make it obvious.
>


if we turn E_STRICT to behave exactly as E_ERROR there is no point keeping
the E_STRICT level.
personally I disagree with turning something which was a pedantic notice in
one version into an unsupported feature which fatals out if you try to use
it in the next.
maybe E_STRICT->E_DEPRECATED->E_ERROR

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--f46d042f972cb8651e04c665a2c2--