What is the recommended error_reporting() setting for development? What about E_STRICT?

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?

Answer 1

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);

Answer 2

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.

Answer 3

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...

Answer 4

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.

Answer 5

You may use error_reporting = -1
It will always consist of all bits (even if they are not in E_ALL)

Answer 6

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:

1. Per the manual, most E_STRICT errors are generated at compile time, not runtime. If you are increasing the error level to E_ALL within your code (and not via php.ini), you may never see E_STRICT errors anyway.
2. E_STRICT is contained within E_ALL under PHP 6, but not under PHP 5. If you upgrade your server to PHP6, and have E_ALL configured as described in #1 above, you will begin to see E_STRICT errors without requiring any additional changes on your part.

Answer 7

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".

Answer 8

ini_set("display_errors","2"); ERROR_REPORTING(E_ALL);