Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62807
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH4AMGiJotNsajr-Q3cxN+k_Xn_1ebTdb9jX8M5GoVcKDw@mail.gmail.com>
References: <AANLkTimWuPXCs-HT6RgQYmH7UKcOYXkeTiMEnBwBXxnt@mail.gmail.com>
	<CAEZPtU6X9gLRALzA+KGKNoF5c7ey-xgJ=0NhjF2qVfD9YJqN+Q@mail.gmail.com>
	<5042946A.80204@sugarcrm.com>
	<op.wjzdwn08idpuyk@damnation.nl.lo.geleia.net>
	<5042A7D6.7050001@lerdorf.com>
	<op.wjzgbuh1idpuyk@damnation.nl.lo.geleia.net>
	<alpine.DEB.2.02.1209031214250.25835@whisky.home.derickrethans.nl>
	<a565e97fdd574cebf2baca1c54c425a2@nebm.ist.utl.pt>
	<50452713.3020307@sugarcrm.com>
	<b6bf26cb6b4d2392d5fd13237669a19d@nebm.ist.utl.pt>
	<5045CAA3.6000409@lsces.co.uk>
	<CAEZPtU77K_wdRErqEQ1ZXj1_sWY2N_UcNkZsL5_h3UfjDmQK1Q@mail.gmail.com>
	<5045E044.9080809@lsces.co.uk>
	<CAL+t6cHD05znYaq7iPNwFNem=zma0-htbPG-Fc3550U-s5jcRA@mail.gmail.com>
	<5045F939.6010806@lsces.co.uk>
	<CAEZPtU4POFm-WJBuYj=bWLMqwtHEViVaZ_2XkE5W3CJfg7uPAg@mail.gmail.com>
	<5045FD98.8080306@lsces.co.uk>
	<CAH-PCH774j+9sV4Oq2Q66BTjRTsd9QtPu5Dnjsf-c_Zg_3nK9w@mail.gmail.com>
	<CAC6CJqbmh0vkSzrjj=miRz2hwVgk6fVPnwPw2wmhykKJZrKUGA@mail.gmail.com>
	<50463317.7000109@lerdorf.com>
	<CAH-PCH4AMGiJotNsajr-Q3cxN+k_Xn_1ebTdb9jX8M5GoVcKDw@mail.gmail.com>
Date: Tue, 4 Sep 2012 13:44:37 -0400
Message-ID: <CAC6CJqbDUH3cJdp0KhY7xxSwScBjLpeEMoRhq9G_VTEj+zN-Tw@mail.gmail.com>
To: PHP Development <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
From: simpleshot@gmail.com (Adam Richardson)

On Tue, Sep 4, 2012 at 1:34 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
> 2012.09.04. 18:58, "Rasmus Lerdorf" <rasmus@lerdorf.com> ezt =EDrta:
>
>
>>
>> On 09/04/2012 09:36 AM, Adam Richardson wrote:
>> > I think Ferenc is correct in that this sounds like there's a custom
>> > error handler somewhere. If the custom error handler collects error
>> > info and then throws an exception (as has been detailed in various
>> > blog posts as one manner of unifying the errors), this would cause the
>> > trouble you're seeing.
>>
>> Only on a new E_STRICT. Even with E_STRICT off by default, custom error
>> handlers are still called, and I think Lester said that turning E_STRICT
>> off made it work. So if this is the cause, then it has nothing to do
>> with E_STRICT being in E_ALL or not, nor whether display_errors is on or
>> off. It would have to do with the custom error handler blowing up on one
>> specific E_STRICT, which I find rather unlikely.
>>
>
> Don't forget that many error handlers check the error level against the
> currently set error_reporting (so that they won't be executed on supresse=
d
> errors and such).
> AFAIR we even promote that implementation in our error handler example in
> our docs.
> That would mean that the error handler main logic is only executed if
> E_STRICT is in the error_reporting.

I was second-guessing my recall I had a similar issue way back, after
Rasmus pointed out that the custom error handler is called even if
E_STRICT is off. However, I just looked back at my framework code, I
see I'm checking to make sure the error level matches, just as Ferenc
pointed out (what a forgetful old man I am.)

So, I think this could still be causing the issue and it's something
worth exploring on Lester's part.

Adam

--=20
Nephtali:  A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com