> - display errors on. > Yes, this is a business decision, 20 servers running upgraded at different > times, > some have less maintenance others have more.. > Seriously, the chance of me even bothering to check one of those log files is > pretty slim. However if the code is producing warning/notices etc. then that > is > likely hiding a unexpected behavior that the client will report as a bug > anyway > later, so it's proved over many years to be cost effective to have them > display, > clients report problems, and we can fix them.. They kind of like that > service.... >
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. 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. > ... > > 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. John Crenshaw Priacta, Inc.
