3

We are working on a PHP application developed for 5.2, but we recently migrated to PHP 5.3. We haven't had the time to go through and fix all the issues with the migrating to PHP 5.3. Specifically, we have a lot of messages:

Declaration of Object::Function should be compatible with that of Parent::function

We can fix these over time, but it will take several weeks. In the meantime we can set:

error_reporting = E_ALL & ~E_STRICT

But this is set globally for the entire script. We want to continue to get the E_STRICT messages for new code we write. Is it possible to just to indicate the functions on which the E_STRICT messages should be ignored? I'm thinking of something similar to Java's @SuppressWarnings annotation.

Brian Fisher
  • 23,519
  • 15
  • 78
  • 82

2 Answers2

0

Unfortunately, strict errors like the one you mentioned are likely to be thrown during compile time, not run time. As noted in the docs:

Warning
Most of E_STRICT errors are evaluated at the compile time thus such errors are not reported in the file where error_reporting is enhanced to include E_STRICT errors (and vice versa).

If that's the case, perhaps you could disable E_STRICT errors in php.ini as you have done,

error_reporting = E_ALL & ~E_STRICT

but then enable them at run time with error_reporting();

error_reporting(E_ALL|E_STRICT);

Maybe that would skip all the compile time ones? (Disclaimer: sounds good, but I haven't tried it yet.)

If they aren't errors that are thrown at compile time, you could do the opposite and enable them in php.ini and only disable them with error_reporting() in the sections you want to ignore, or by setting a custom error handler with set_error_handler() that selectively ignores strict errors thrown from certain places.

Wiseguy
  • 20,522
  • 8
  • 65
  • 81
0

Unfortunately, php's @ suppressor only works with expressions rather than class definitions. Your specific example also appears to be tied to a bug, now marked bogus .. I think that it is a bug, though, but I think the warning should actually show up more.

What you can do, though, is change the error_reporting level multiple times throughout the script assuming your new code is easily divided from your old code. If you're working with the same classes, though this becomes a lot harder.

You can use an error handler to possibly filter some functions and methods you don't want to report on, though:

set_error_handler('GOON', E_STRICT);
function GOON($errno, $errstr) {
   if (is_strict_function($errstr)) {
      echo "$errstr\n";
   }
}
function is_strict_function($str) {
   foreach (
      array(
         'xzin::goon'
         //Other functions or methods go here
      )
      as $fnc
   ) { 
      if (strpos($str, $fnc) !== false) {
         return false;
      }
   }
   return true;
}

error_reporting(E_ALL | E_STRICT);

class xzin extends zin {
   function goon($a) {}
}
class tzin extends zin {
   function goon($a) {}
}
class zin {
   function goon() {}
}

Prints: "Declaration of tzin::goon() should be compatible with that of zin::goon()" only.

Explosion Pills
  • 188,624
  • 52
  • 326
  • 405