Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62026
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 74.125.82.170 cause and error)
Message-ID: <6214E40C106D49398CC920D8587815B4@pc>
To: "Nikita Popov" <nikita.ppv@gmail.com>,
	"Ferenc Kovacs" <tyra3l@gmail.com>
Cc: "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>
Date: Sat, 4 Aug 2012 02:16:29 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Error handling brainstorming
From: sv_forums@fmethod.com ("Stan Vass")

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).

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.

I've found this speeds up the development process, keeps bug count down and 
protects the site/app's data in case of bugs.

Stan