Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68687
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH7-oZT7u0KB7bbDFNmZGeMiSUcU0-Shsp7rXmwaOb3muA@mail.gmail.com>
References: <CAH-PCH7-oZT7u0KB7bbDFNmZGeMiSUcU0-Shsp7rXmwaOb3muA@mail.gmail.com>
Date: Thu, 29 Aug 2013 17:31:46 +0200
Message-ID: <CAH-PCH5-tODWcqdkiV+njdi1Kd2UntKtX+F6+DVUWWPcOQ-oaA@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bdc1870c9a79c04e517cd17
Subject: Re: handling non-fatal compile-time errors
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7bdc1870c9a79c04e517cd17
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 8, 2013 at 5:11 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:

> Hi,
>
> I've just bumped into https://bugs.php.net/bug.php?id=3D65322 recently, a=
nd
> I would like you get some opinions on the issue.
> Personally I think that it is a really bad design to introduce
> pedantic(E_STRICT) errors which can break basic functionality of the engi=
ne
> (calling the registered autoloader), so if there is no viable solution to
> make the autoloader work for these kind of errors, I would like to propos=
e
> removing the offending errors and make it a rule to not add compile-time
> non-fatal errors until the problem is resolved.
>
> ps: on a related note, somehow I got the feeling that Lester complaining
> that E_STRICT errors fataling/crashing the application migrated to PHP 5.=
4
> was related to this problem, and I'm a bit sad that we didn't managed to
> figure this out back then.
>
> --
> Ferenc Kov=C3=A1cs
> @Tyr43l - http://tyrael.hu
>

for the record this is a known(as reported) since 2007:
https://bugs.php.net/bug.php?id=3D42098
and reported again in 2011:
https://bugs.php.net/bug.php?id=3D54054&edit=3D2

do we agree with the resolution from the 2007, eg. it is fine that there an
undefined list of errors (from all and any error level) which behave
differently than most others (as it won't trigger the autoloader) and even
an E_STRICT error can blow up a reasonably written application (an expected
error occurs, which happens to be compile time, which will trigger the
autoloader, which will fail to autoload it's dependencies, which will
generate class not found fatal error).

I expect much more similar reports now that people start to migrate to
5.4/5.5 where E_STRICT is part of E_ALL(and that the error reporting
infrastructure in an average application is more likely to depend on
autoloading nowadays).

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7bdc1870c9a79c04e517cd17--