0

I have noticed that using php's error_reporting function at runtime seems to cause it to report notices that have occurred previously.

Is this by design, or is there a way to prevent it?

$er = error_reporting(E_ERROR);
$m = new MyClass();
$m->myFunction();
//error_reporting($er);

In the above code, myFunction() calls 3rd-party code that raises warnings and/or "strict" notices. If the last line is commented out as it is above, those warnings and notices are not returned. However, if I uncomment that line so that error reporting can return to normal, the strict notices, but not the warnings, are reported at that point.

Update I think this is not a problem with error_reporting as I had originally thought, but instead an issue with Pear, the 3rd-party code I'm using.

See my post at php pear mail extension raises strict notices

Community
  • 1
  • 1
susie derkins
  • 512
  • 2
  • 6
  • 17
  • That would not be how error_reporting works. Most likely, you use that code later on as well. – Wrikken May 01 '13 at 19:55
  • @wrikken - not quite sure what you mean. `error_reporting` function should indeed set what types of errors are and are not displayed at runtime – susie derkins May 01 '13 at 20:12
  • Yes, but it doesn't 'save' errors for later, which is what I meant. If by uncommenting that line your get errors, the errors are occuring _after_ that line. – Wrikken May 01 '13 at 20:14
  • Note that most likely your confusion is: (1) setting error reporting low (2) including function definitions / classes/ etc (3) setting error reporting high (4) using those functions & classes will now report the errors, `include`-ing them with low error reporting does nothing for errors triggered on call time with higher error reporting. – Wrikken May 01 '13 at 20:16
  • I understand why you might think the errors occur subsequently, but those are the only lines of code. There is nothing further to trigger errors. Perhaps the 3rd-party code that myFunction calls is running asynchronously and doesn't actually execute until later...although I doubt it. – susie derkins May 01 '13 at 20:24
  • You must have a might weird setup... [as you can see from this running example](http://codepad.org/X1RR4UkC), the first error never appears, only the second one. What happens if you call `exit` _directly_ after your 2nd `error_reporting` call? – Wrikken May 01 '13 at 20:28

1 Answers1

2

I have noticed that using php's error_reporting function at runtime seems to cause it to report notices that have occurred previously.

What you said is just regular behaviour at must related to parts of your code which you havn't posted. Check my example. It will call a non static method statically what will cause a E_STRICT message:

Class A { 
    public function notStatic() {}
}

$a = new A();

error_reporting(~E_ALL);
$a::notStatic();   // ... silence

error_reporting(E_ALL);
$a::notStatic();   // Strict standards: Non-static method A::notStatic() should not be called statically in
hek2mgl
  • 152,036
  • 28
  • 249
  • 266
  • you have suppressed a warning, not a strict notice. As I clarified, it's the notices that are subsequently raised – susie derkins May 01 '13 at 20:09
  • Thanks, that's a helpful example - I had just started trying to trigger a strict notice unrelated to the 3rd-party code that I'm using so that I can test. Using your example, I get the behaviour that one would expect. However, the situation I describe in original post is not 'wrong' - it is indeed happening. My assumption that it may have been related to `error_reporting` appears to be incorrect. Perhaps there is some asynchronous code in the 3rd-party code. (which is sending email with Pear) – susie derkins May 01 '13 at 20:32
  • Thanks - you are completely right, and I have posted a more direct question at http://stackoverflow.com/questions/16326502/php-pear-mail-extension-raises-strict-notices – susie derkins May 01 '13 at 21:07