29

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?

SeanDowney
  • 17,368
  • 20
  • 81
  • 90

8 Answers8

44

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);
Pacerier
  • 86,231
  • 106
  • 366
  • 634
Jim
  • 72,985
  • 14
  • 101
  • 108
  • 1
    Just notice that with PHP >= 5.4 the E_STRICT is included withing E_ALL – mTorres Aug 22 '14 at 11:12
  • 1
    @hakre, I'm not sure I understand your edit on this answer. You're clearly implying that on 'esoteric systems', it is possible that `-1 != ~0`. What are these esoteric systems, and do they really exist? Would I be right to guess that PHP's integers are stored in whatever format the C compiler used to compile PHP uses, and that you're thinking of a hypothetical scenario in which somebody compiles PHP on, say, a one's complement C compiler? Anyway, wouldn't simply modifying Gordon's code snippet be better than leaving what's effectively an "actually, the last paragraph is wrong" edit? – Mark Amery Sep 11 '14 at 21:53
  • 1
    -1 is a number, - a numeric operator. depending on how negative integers are handled it can represent ~0 but must not. Where it doesn't, that are those systems which I named "esoteric". What technically is wrong is that you want to use the bit-operator ~ instead of a numeric operator. See http://stackoverflow.com/questions/1967360/what-does-this-operator-mean-here this is what you normally want to express. So the code is less wrong in using the more correct expression. And yes, I have experienced it once. But that's a bit ago, last time I was asked I already couldn't reproduce from mind. – hakre Sep 12 '14 at 11:46
  • @hakre, I've undone the edit. This is about hard science, not semantics. **Both are** technically correct. Until you can **name one** machine where `error_reporting(-1)` gives you different observed behavior from `error_reporting(~0)`. – Pacerier Jan 26 '15 at 11:51
10

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.

Eduardo Marinho
  • 446
  • 4
  • 14
5

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

Sk8erPeter
  • 6,899
  • 9
  • 48
  • 67
Daniel Papasian
  • 16,145
  • 6
  • 29
  • 32
2

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

RiaD
  • 46,822
  • 11
  • 79
  • 123
2

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.

Jan Krüger
  • 17,870
  • 3
  • 59
  • 51
1

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.
A J
  • 3,970
  • 14
  • 38
  • 53
stormlash
  • 1,177
  • 8
  • 9
0

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

Pablo Borowicz
  • 911
  • 2
  • 9
  • 21
-1

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

Tim Boland
  • 10,127
  • 8
  • 27
  • 25
  • OK, PHP's function names are case insensitive, but you should rather use it the way it should be used (e.g. `error_reporting( E_ALL | E_STRICT )`, where the function's name is not written with capital letters). By the way, `E_ALL` doesn't contain `E_STRICT` in PHP versions less than 5.4. – Sk8erPeter Dec 26 '11 at 16:16