RE: [PHP-DEV] consider reverting E_ALL with E_STRICT
> - 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.
Thread (14 messages)