On Tue, Sep 4, 2012 at 1:34 PM, Ferenc Kovacs <tyr...@gmail.com> wrote: > > 2012.09.04. 18:58, "Rasmus Lerdorf" <ras...@lerdorf.com> ezt írta: > > >> >> 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 supressed > 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 -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
