I was working with a PEAR package in a PHP 5.2 environment. Naturally, I was getting some E_STRICT errors. I like to have all my code strict compliant, so I always develop with E_STRICT turned on. I wasn’t about to start changing the PEAR code, so I thought I’d just use error_reporting and disable E_STRICT reporting right before using the offending code — then I’d restore the original error_reporting value.
$oldErrorReportingValue = error_reporting(); error_reporting($oldErrorReportingValue ^ E_STRICT); // call offending PEAR code… error_reporting($oldErrorReportingValue);
This didn’t work. No matter what I set error_reporting to, the E_STRICT errors would keep showing up in my logs. I found others with the same problem, but I was led on a wild goose chase:
- http://pear.php.net/bugs/bug.php?id=9950
- https://bugs.php.net/bug.php?id=40244
- http://www.php.net/manual/en/function.error-reporting.php
One of the causes was PEAR running the non-strict code during a registered shutdown handler. Another cause was the strict errors getting thrown at compile time. But neither of these applied to my case.
After messing around for quite a while I discovered the answer in the set_error_handler documentation. My custom error handler was the cause…
“It is important to remember that the standard PHP error handler is completely bypassed [...] unless the callback function returns FALSE. error_reporting() settings will have no effect and your error handler will be called regardless – however you are still able to read the current value of error_reporting and act appropriately.”