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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
