I’m just wondering who else codes their PHP to the rigorous level where you can turn E_ALL on and not see any errors. We should start a club - the E_ALL club.
I use a routine to slurp all non-fatals (warning, strict, notice) into a log array then, if returning html, I attach a javascript snippet which reports the errors in the Firebug console. This way I can get things roughed out to show the client but before the code goes into production all of those notices are dealt with.
It’s a bitmask, so I assume -1 to be a shortcut. You can also give it a large ^2, from the man:
So in place of E_ALL consider using a larger value to cover all bit fields from now and well into the future, a numeric value like 2147483647 (includes all errors, not just E_ALL).
Just to be pedantic, you should use the same (hopefully max) reporting in prod as dev. You just don’t show them (eg instead throw a 404/500 to the user)
Off Topic:
> I use a routine to slurp all non-fatals (warning, strict, notice) into a log array then, if returning html, I attach a javascript snippet which reports the errors in the Firebug console.
Have you looked into FirePHP; it would save you from attaching any JavaScript snippet anywhere and keeps PHP-related logging in PHP.
Okay, you’ve convinced me.
I’m switching to E_ALL | E_STRICT as well 
We use E_ALL | E_STRICT. Sure, E_STRICT might only be “suggestions” but they’re there for good reason.
That’s wrong imho. Throwing a 500 error because of a notice and impeding the usability of your site on something non-critical seems ridiculous. You should log any warnings/notices but not stop the user accessing your content.
The only reason to use anything less than E_ALL is if you’ve inherited someones bad code and don’t have the time/budget to fix it. I use E_ALL | E_STRICT in my own code.
Using anything less than E_ALL is akin to closing your eyes so the lion doesn’t eat you.
E_ALL | E_STRICT for me. E_STRICT is useful because it shows you implementation mistakes which are bad practice.
It’s all about binary arithmetic, here’s a quick table showing the error levels, their integer values and their (32 bit) binary values.
ERROR LEVELS IN PHP 5.3.x
================================================================
E_ERROR 1 00000000000000000000000000000001
E_WARNING 2 00000000000000000000000000000010
E_PARSE 4 00000000000000000000000000000100
E_NOTICE 8 00000000000000000000000000001000
E_CORE_ERROR 16 00000000000000000000000000010000
E_CORE_WARNING 32 00000000000000000000000000100000
E_COMPILE_ERROR 64 00000000000000000000000001000000
E_COMPILE_WARNING 128 00000000000000000000000010000000
E_USER_ERROR 256 00000000000000000000000100000000
E_USER_WARNING 512 00000000000000000000001000000000
E_USER_NOTICE 1024 00000000000000000000010000000000
E_STRICT 2048 00000000000000000000100000000000
E_RECOVERABLE_ERROR 4096 00000000000000000001000000000000
E_DEPRECATED 8192 00000000000000000010000000000000
E_USER_DEPRECATED 16384 00000000000000000100000000000000
E_ALL 30719 00000000000000000111011111111111
E_ALL & ~E_DEPRECATED 22527 00000000000000000101011111111111
E_ALL | E_STRICT 32767 00000000000000000111111111111111
-1 -1 11111111111111111111111111111111
Off Topic:
Sorry for the horizontal scrolling, Sitepoint’s code boxes are fixed-width and not wide enough for the lines above.
Yes, perhaps a bad eg, my point was never turn them off. Error reporting is there for a reason and it should be at max in all environments, it is purely how you deal with them that differs: in prod, don’t display anything, throw appropriate http codes if needed (eg un caught exceptions); in dev, display as much as poss.
Off Topic:
I have, but I wrote the above nearly a year before FirePHP was born. Also, unlike FirePHP the system logs to the database if dev is turned off. It’s pretty heavily integrated into my system error handling. I’m fastidious about errors - heck I consider any query that takes more than a tenth of a second to resolve to be an error and log it.
I use -1 during development, as the documentation states ‘All Errors’, which I assume to mean everything.
Would someone be so kind to elaborate a little for me on what status really is everything if not -1?
E_ALL = 30719
E_ALL | E_STRICT = 32767
Again, I assumed there would be some correlation between -1 and a combination of the available E_* constants.
Edit:
Hmm, according to the documentation, maybe it’s just a short-cut that guarantees ‘All Errors’ regardless of how they bugger around with E_* constants in the future.
Passing in the value -1 will show every possible error, even when new levels and constants are added in future PHP versions.
I thought it was common practice to do so anyway
Nah, E_ALL is a bit too much for me. I’m going for E_ALL & ~E_NOTICE
Though I avoid E_NOTICE mistakes as much as I can (not initializing variables and such), I just think notices are annoying