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?
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
You can also use
which will always enable all errors. Which is more semantically correct as:
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
E_ALL | E_STRICT for development with PHP before 5.2.0.
E_RECOVERABLE_ERROR and 5.3 introduces
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_STRICTerrors are generated at compile time, not runtime. If you are increasing the error level to
E_ALLwithin your code (and not via php.ini), you may never see
E_STRICTis contained within
E_ALLunder PHP 6, but not under PHP 5. If you upgrade your server to PHP6, and have
E_ALLconfigured as described in #1 above, you will begin to see
E_STRICTerrors 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”.