Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62027
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: <6214E40C106D49398CC920D8587815B4@pc>
References: <CAH-PCH7874id459NTuMqL6pzL=feRtaWUAiPiSqPDa73tnFy9w@mail.gmail.com>
	<CAF+90c_R7D3OC5ubzOAw46E3hoPdeyOYD5H2vXU5Uy_CqirOVg@mail.gmail.com>
	<6214E40C106D49398CC920D8587815B4@pc>
Date: Sat, 4 Aug 2012 01:37:23 +0200
Message-ID: <CAH-PCH5A+0-7qw3ut-Sf_Ax9iZ4m-YFj25T_33UUrrDY2pUxDg@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=f46d042f972c8e960404c66502d8
Subject: Re: [PHP-DEV] Error handling brainstorming
From: tyra3l@gmail.com (Ferenc Kovacs)

--f46d042f972c8e960404c66502d8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 is, 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 error
> that's being reported. So I decided this by observing the real-world erro=
rs
> 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.
see http://www.mail-archive.com/internals@lists.php.net/msg24665.html about
the original proposal and the discussion and you can see the list of
E_STRICT errors in the 5.4 branch here:
http://lxr.php.net/search?q=3DE_STRICT&defs=3D&refs=3D&path=3D%28*c%29+OR+%=
28*h%29&hist=3D&project=3DPHP_5_4
stuff like using non-existing variables and constants are E_NOTICE, method
signature mismatches are either fatal errors or warnings AFAIR.


>
> PHP should not split the language semantic into loose, less loose and
> strict, there should be just one set of semantics: the PHP semantics, and
> when code does something that doesn't fit, it shouldn't be an ignorable
> warning.
>

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.
from all of the errors levels only E_DEPRECATED and E_STRICT is what means
that atm your code works as intended.
but for E_DEPRECATED it will not work in the future, and for E_STRICT it is
either does it's job sub optimally or the requested operation is just
stupid (but doable).
at least this is the theory, if you know something with doesn't in line
with this, we could talk about it. :)


>
> I've found this speeds up the development process, keeps bug count down
> and protects the site/app's data in case of bugs.


I agree that developing with E_ALL (including E_STRICT) is a good developer
mentality.
But I would find it too intrusive to start forcing everybody with the next
version to either fix every E_STRICT in their code, and even more weird if
we do that but still allow them to write code with full of E_WARNING and
E_NOTICE and get away with that.


--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--f46d042f972c8e960404c66502d8--