What is the recommended error_reporting() setting for development? What about E_STRICT?
-
09-06-2019 - |
Question
Typically I use E_ALL
to see anything that PHP might say about my code to try and improve it.
I just noticed a error constant E_STRICT
, but have never used or heard about it, is this a good setting to use for development? The manual says:
Run-time notices. Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.
So I'm wondering if I'm using the best error_reporting
level with E_ALL
or would that along with E_STRICT
be the best? Or is there any other combination I've yet to learn?
Solution
In PHP 5, the things covered by E_STRICT
are not covered by E_ALL
, so to get the most information, you need to combine them:
error_reporting(E_ALL | E_STRICT);
In PHP 5.4, E_STRICT
will be included in E_ALL
, so you can use just E_ALL
.
You can also use
error_reporting(-1);
which will always enable all errors. Which is more semantically correct as:
error_reporting(~0);
OTHER TIPS
Use the following in php.ini:
error_reporting = E_ALL | E_STRICT
Also you should install Xdebug, it can highlight your errors in blinding bright colors and print useful detailed information.
Never let any error or notice in your code, even if it's harmless.
In my opinion, the higher you set the error reporting level in development phase, the better.
In a live environment, you want a slightly (but only slightly) reduced set, but you want them logged somewhere that they can't be seen by the user (I prefer syslog
).
http://php.net/error_reporting
E_ALL | E_STRICT
for development with PHP before 5.2.0.
5.2 introduces E_RECOVERABLE_ERROR
and 5.3 introduces E_DEPRECATED
and E_USER_DEPRECATED
. You'll probably want to turn those on if you're running one of those versions.
If you wanted to use magic numbers you could just set the error_reporting
value to some fairly high value of 2^n-1
- say, 16777215
, and that would really just turn on all the bits between 1..n
. But I don't think using magic numbers is a good idea...
In my opinion, PHP has dropped the ball a bit by having E_ALL
not really be all. But apparently it's going to be fixed in PHP 6...
In newer PHP versions, E_ALL includes more classes of errors. Since PHP 5.3, E_ALL includes everything except E_STRICT. In PHP 6 it will alledgedly include even that. This is a good hint: it's better to see more error messages rather than less.
What's included in E_ALL is documented in the PHP predefined constants page in the online manual.
Personally, I think it doesn't matter all that much if you use E_STRICT. It certainly won't hurt you, especially since it may prevent you from writing scripts that have a small chance of getting broken in future versions of PHP. On the other hand, in some cases strict messages may be too noisy, perhaps especially if you're in a hurry. I suggest that you turn it on by default and turn it off when it gets annoying.
You may use error_reporting = -1
It will always consist of all bits (even if they are not in E_ALL)
Depending on your long term support plans for this code, debugging with E_STRICT
enabled may help your code to continue working in the distant future, but it is probably overkill for day-to-day use. There are two important things about E_STRICT
to keep in mind:
- Per the manual, most
E_STRICT
errors are generated at compile time, not runtime. If you are increasing the error level toE_ALL
within your code (and not via php.ini), you may never seeE_STRICT
errors anyway. E_STRICT
is contained withinE_ALL
under PHP 6, but not under PHP 5. If you upgrade your server to PHP6, and haveE_ALL
configured as described in #1 above, you will begin to seeE_STRICT
errors without requiring any additional changes on your part.
Not strictly speaking of error_reporting, I'd strongly suggest using any IDE that automatically shows parsing errors and common glitches (eg, assignment in condition).
Zend Studio for Eclipse has this feature enabled by default, and since I started using it, it has been helping me a lot at catching errors before they occur.
For example, I had this piece of code where I was caching some data in the $GLOBALS
variable, but I inadvertently wrote $_GLOBALS
instead. The data never got cached up, and I'd never knew if Zend didn't tell me: "Hey, this $_GLOBALS
thingy appears only once, that might be an error".
ini_set("display_errors","2"); ERROR_REPORTING(E_ALL);