And the first time your network infrastructure has even a tiny hiccup you broadcast your database name/username/password to the whole world. Not an excellent business decision.
I've yet to see a php notice / warning echo out a name/password etc... - anyway these are normally not public services... - no big deal.
Here's the reality, bugs exist, Users find them.. Users are really really bad at describing and reporting them "It does not work"... I can take 3-4 rounds (and a few days) of back and forth before you actually discover what the real problem is, it wastes their time (and annoys them) and yours.. Where as now. they report a screenshot or pasted error.. the problem is fixed in minutes.. with the line number and file of where the problem is.... Client is very happy, and pays quicker ;)
Actually this impression that the group espouses 'do not have display errors on in production' does not apply to all situations, it may be good for your new dotcom super site, but for applications that have to work correctly and run business operations, the value proposition can be the other way round.
Configuring the server to mail error logs to you isn't hard. The end result is actually faster and more reliable than waiting for a user to care enough to email you about a problem they see.
Reminds me of the backup emails, you set up warnings for the backup failing, but when the server fails, you find out the backup emails failed months ago.... Or you send out a daily backup email and everyone learns to ignore it.. It's a nice idea, but only sending me warnings/errors on this directory but not the other one and make sure it get's sent even if there is a fatal error.. get's complicated quickly. KISS is what tends to works here.
Did anyone actually argue about the downsides of this?
Basically the cons come down to old generating more non-fatal errors than it did before. This is a minor BC break roughly on par with plenty of other small breaks introduced in 5.4.
I do see something important in all this though. I think the documentation should explicitly state that E_ALL means absolutely everything, now and forever. We got into this mess in the first place because people didn't want to change the meaning of E_ALL when E_STRICT was added. We're redefining E_ALL now to include E_STRICT, so it means all again, but I think we need a future compatible definition that clarifies that this means all present errors, PLUS any future errors that get added for any reason. This way adding new error types would not need to be considered a BC break.
It is a minor BC break, when you spend an hour clearing up the mess, it's not too bad, but I had to ask, was this hour a waste of my time, did it help the code quality, and what where the benefits.. I could not see any, only the waste of time..
I think the fact is now, that most of the code I work with will have to do error_reporting(E_ALL & ~E_STRICT). I'm guessing it's unlikely that more error codes will be added that are as valueless as E_STRICT, so I think it is something to live with now..., Just in hindsight it may not have been a great decision adding it to E_ALL...
Regards
Alan
John Crenshaw
Priacta, Inc.