Many developers who work on Drupal (or other web/PHP) projects have error reporting disabled in their local or shared dev environments. They do this for a variety of reasons: some don't know how to enable it, some are annoyed by the frequency of notices, warnings, and errors, and some don't like to be reminded of how many errors are logged.
But there are a few important reasons you should make sure to show all errors when developing:
- When there's a major issue on your production site, you will need to go into the logs and look for clues as to what's going wrong. And when you do, the fewer "noisy" log messages you have, the better.
- At a certain level, the volume of messages being logged will harm your site's performance (even if you're using syslog instead of database logging). I've heard of cases where page load performance was 1.5x or 2x slower due simply to the volume of logged PHP messages.
- Some of the most pernicious bugs are those related to variables not being instantiated, objects being accessed as arrays, etc.—all things that are explicitly logged as notices and warnings (but won't break a site).
- Notices and warnings help you to identify areas of your site where your PHP code style might be wanting. This is a sign that you should start using PHP CodeSniffer or PHP Mess Detector to help improve the quality of your code.
- One of the easiest ways to see if a contributed module is up to snuff is to enable it and make sure no new notices/warnings/errors start popping up all over your site.
Unfortunately, for many Drupal sites, the damage is already done, and if you wade into the system logs or the watchdog log, you'll find dozens or even hundreds of errors for every page request. Or, worse, you'll find that the site administrators completely disabled logging because the volume of errors caused severe performance issues.
What NOT to do
If you're doing any of these things, change your behavior immediately to start making your site better.
- Don't silence PHP errors. On production, tell Drupal to not log message to the screen, but to at least log them in either syslog or the database (syslog preferred for performance reasons; plus it integrates with Acquia Cloud logs and tools like ELK or SumoLogic).
- Don't use
@to silence PHP errors (see should I use @ to hide errors in PHP?). You're just masking a problem; instead fix it when you discover it. - Don't turn off all error logging. Some people disable error logging entirely, on dev, local, and production. This is a very bad idea, and will result in a ton of technical debt.
Silencing errors or disabling all logging is a very bad idea; user berkes on Drupal Answers has a great analogy:
Errors have a very important role: they indicate that something is wrong. Surpressing that does not solve the underlying problem. This is also called the "Russian Method:" When the alarm-light in a nuclear plant starts blinking, just remove the lightbulb. Alarm-light no longer blinks; no problems. (Source)
This comment refers to the Chernobyl disaster. When a cascading set of warnings were intentionally silenced, resulting in one of the greatest man-made disasters of the 20th century. There's a reason PHP has an error logging mechanism—it's so you can fix your fragile site before it ends in disaster.
What TO do
You can't fix what you can't see, so the most important thing is to show all errors while developing on local and shared development environments. Drupal.org has a documentation page showing how to do this: Show all errors while developing. Drupal VM includes a log viewing utility you can use to see errors. Most web hosts have an interface where you can view logs either live or in downloadable form. Know them, use them.
You should have an error budget: "If there are ever X logged notices/warnings/errors or more during Y period of time, we will stop working on new features on the site and work instead to fix those problems." For some teams, X is one or more; for others, they can live with a few errors or notices on certain pages. The key is to make sure you keep a lid on it. You don't want to have a super-fragile site that has tons of logs you have to wade through when things go wrong.
If your site is already over your error budget (e.g. if you see more errors on your home page than the home page in your development environment), make an effort to fix errors now. The ROI is huge, because most of the time, one small fix (e.g. making sure a variable is set correctly somewhere) can solve dozens or even thousands of errors.
Hide messages on the screen in production, but log them to syslog. On /admin/config/development/logging, set "None" for "Error messages to display"), and make sure you have the Syslog module enabled. If you have a low-traffic site, or just need a really simple interface for viewing logged messages (and can live with the potentially-severe performance impact when there's a lot of activity), you can consider using Database Logging instead of Syslog. Acquia Cloud even streams and aggregates your logs when you use Syslog; see About Acquia Cloud Logging.
The Drupal 6 conundrum
One of the reasons I finally wrote this blog post (I've had a draft sitting in my files for over six years!) was because a few recent incidents have highlighted a major problem for those still running Drupal 6 websites: Drupal 6 core, and many Drupal 6 contributed modules, throw a lot of notices and warnings if you run them with an actively-supported PHP version (currently only PHP 5.6 or 7.0). Since PHP 5.3 and 5.4 are rarely supported these days, and PHP 5.5 is getting harder to find, there are many cases where you have to run a Drupal 6 site on PHP 5.6 servers... meaning your logs get quite full.
I'd argue that you should take this as reason #1284 why you should upgrade to Drupal 7 or 8 ASAP. In rare circumstances where you absolutely must keep a Drupal 6 site up and running, you might have to break some of the rules I outlined above—either run an older, insecure, outdated, and slow version of PHP so the logged messages aren't to an extreme level, or turn off error logging. This should be seen as the "nuclear option," and should probably motivate you to either drop any modules on an old Drupal site that cause lots of messages, or push for upgrading sooner rather than later.
