Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62028
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 209.85.212.182 cause and error)
Message-ID: <250022DBD6DE4F50BBAD1CB655909382@pc>
To: "Ferenc Kovacs" <tyra3l@gmail.com>
Cc: "Nikita Popov" <nikita.ppv@gmail.com>,
	"PHP Internals" <internals@lists.php.net>,
	"Andrew Faulds" <ajf@ajf.me>,
	"Etienne Kneuss" <colder@php.net>
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>
Date: Sat, 4 Aug 2012 02:44:16 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0041_01CD71EB.09F1D7B0"
Subject: Re: [PHP-DEV] Error handling brainstorming
From: sv_forums@fmethod.com ("Stan Vass")

------=_NextPart_000_0041_01CD71EB.09F1D7B0
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 errors 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.:


  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 the 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 =
then 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.
------=_NextPart_000_0041_01CD71EB.09F1D7B0--