Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62032
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 209.85.212.176 cause and error)
Message-ID: <600F7B5AAF5744B695DBFD7E81A0C6AA@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><250022DBD6DE4F50BBAD1CB655909382@pc> <CAH-PCH6PNrCk8yrtgq8sGN=+Jk=z1Y6EEvLQRq+TEZfDkHJjHQ@mail.gmail.com>
Date: Sat, 4 Aug 2012 07:02:31 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0022_01CD720F.1DDC86C0"
Subject: Re: [PHP-DEV] Error handling brainstorming
From: sv_forums@fmethod.com ("Stan Vass")

------=_NextPart_000_0022_01CD720F.1DDC86C0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



  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
I do think there's no point keeping the E_STRICT level. In fact, there's =
no point keeping any level except=20

- E_WARNING (strictly for developer "tips" like deprecated =
functionality, and not for say division by zero errors or Stream I/O =
errors like it is today);
- E_ERROR (everything that's not a developer "tip" but an error, should =
be this type, not a notice/warning/strict);
- E_FATAL_ERROR (direct script halt).=20

That's just how I see it. Today we have these instead:

- E_ERROR
- E_WARNING
- E_PARSE
- E_NOTICE
- E_CORE_ERROR
- E_CORE_WARNING
- E_COMPILE_ERROR
- E_COMPILE_WARNING
- E_USER_ERROR
- E_USER_WARNING
- E_USE_NOTICE
- E_STRICT
- E_RECOVERABLE_ERROR
- E_DEPRECATED
- E_USER_DEPRECATED

Most of those have no reason to exist and especially they have no reason =
to be exposed as different severities at the user level. It seems like =
the severity levels have become a poor man's error *type* codes, which =
are needed, and at much more granular level, but as this is a severity, =
that's not the place to differentiate them.

I never spoke about E_STRICT going fatal in the next version of PHP. I'm =
saying this in the context of my advice about using an error handler. I =
do this in my error handler (not just development, but also production), =
but still I think it could be a nice long-term goal to cleaning up PHP.

Stan
------=_NextPart_000_0022_01CD720F.1DDC86C0--