PHP Error Reporting and Why You Should Care

An article by admin    No Comments

If you’re a PHP developer, and you prefix questionable function calls with the “@” symbol, you should be aware that I’m onto you!  If the first line of code you write after <?php is “error_reporting(0);”, then we shouldn’t be friends anymore.  Error reporting in PHP is really really really important, and you should probably also stop reading, because this article will just fill your soul with rage.

Keep in mind, this article isn’t about whether or not you should add a newline after a conditional statement, or PDO vs. Non-PDO queries.  This article is about debugging, fixing errors before an epic-fail moment, and how to handle errors in PHP.

Side note: turning OFF error reporting for production/general-user accessible sites IS recommended as displaying PHP errors to normal visitors is a security risk.

Introduction

Ever have one of those moments where everything you’ve just coded suddenly stops working, and you’re staring down a blank white screen of death wondering if you should’ve probably pursued a different profession?  If so, then read on my fellow programmer.

At least a basic knowledge of PHP error reporting is a crucial aspect of being a web developer, and this is true for projects of any size, whether it’s for clients or personal fun.  When I started learning PHP, I once spent almost an entire day re-writing and re-re-writing a stupidly long file trying to find out why all I saw was a blank white screen.  As it turns out, I neglected the almighty semicolon at the end of a variable.  That’s right.  I wasted a whole day over a single character.  Know why?  I hadn’t turned my error reporting on, so instead of seeing ANYTHING, I saw absolutely zero.

Why you should develop with PHP error reporting at the highest level

The quickest answer is “so your websites don’t fail”.  To elaborate slightly; all of those pesky PHP warnings, and more notable- PHP fatal errors are performance and UX killers.  There’s only so many warnings that you can have before the performance implications become severe, and your site grinds to a startling halt.

Don’t believe me?

• 10k notices, with error_reporting and display_errors enabled : 5,162.76 ms
• same, but with display_errors disabled : 136.18 ms
• same, but with error_reporting disabled too : 117.79 ms
• and, finally, after patching the code so it doesn’t produce any notice anymore : 19.51 ms

Src: http://stackoverflow.com/a/1869185 and http://www.nexen.net/articles/dossier/18638-ne_faites_pas_derreur.php

WordPress (sadly) is possibly the worst when it comes to ignored and suppressed errors, which I assume is partially due to the size of the community, and partially related to the number of inexperienced plugin developers.

For example, using the Wasp wordpress plugin, before it’s activated on THIS site (which for reference is quite up to date, and has very few plugins), this is what my dashboard looks like:

Good!  No errors!  Or so you think.  Here is what my dashboard in Wasp looks like 3 page loads later after enabling the wasp plugin:

Yes, that’s right.  1,149 errors were thrown between 12 different files in THREE page loads.  And after a bit over a day, you’d be looking at hundreds of thousands of instances of an error.  Hmm.  Almost seems like developers hate when their code works properly!

WordPress is fast, but not so fast that the sheer quantity of errors generated in any given page load isn’t making it okay not to use some heavy duty caching.

Other very very important reasons to resolve your errors as they occur:

• Scalability.  Need to handle more users, more pageviews, and not piss off your users?  You should probably fix your code
• Extendability.  New feature addition?  Let’s all cross our fingers and hope you aren’t wasting your time in the very likely event that you’ll need to tap into any existing code you may have
• The inevitable rage that will be unleashed by any other competent developer who may be so unlucky as to inherit your codebase, or that you may need help from

Enabling Error Reporting in php.ini

This is a one line fix.  Crack open your php.ini file (if you’re working locally via mamp, it’s located in /Applications/Mamp/bin/php/[YOUR VERSION OF PHP]/conf/php.ini), and do a search for “error_reporting“.

If you found this article because your screen is void of anything including a fail message, that means your error_reporting line looks something like:

error_reporting = Off

This is a problem with a simple solution.

error_reporting = E_ALL

You may need to restart Mamp, or you may just need to refresh your page after saving that change, but that’s the root of all PHP error reporting in one beautiful line.

Enable Error Reporting in Your Codebase

I personally prefer to include my code-side error preferences in conditional tags so that my errors are always displayed in development environments, and are never displayed on a production environment, but you that’s a topic for another article.

What you need to know here is:

error_reporting( E_ALL );
ini_set( 'display_errors', 1 );

The preceding code show be included at the top of whichever file you’re loading, and is typically included at the top of index.php in MVC style environments, or if you have a file that is included in every other file (at the top!) such as config.php or inc.php (whatever people call it), add the error_reporting and ini_set params to the top.

Now that we can see the errors… FIX THEM

I’m only going to say this once.

Do not suppress errors using the “@” symbol.  Do not ever @include( ‘your-file-here.php’ );  Just make sure the file exists people, it’s really not rocket science!

And if you’re doing something such as including a file that you’re not 100% sure exists, it’s also not that hard to just see if it exists first…

if( file_exists( $your_file ) )
{
  include( $your_file );
}

But most importantly, now that we can see the errors, we can fix them (hint hint).  And before you get all scared about how much time this is going to take you to go back and fix your code and [insert other whining here], 99% of the errors I see in the code that hits my desk are simply related to undefined variables.  That’s right.  Developers are notorious for taking shortcuts, and one of those shortcuts just happens to be the biggest cause of PHP warnings and errors on the planet.  See even my introductory content on Getting Started with PHP where I address the same issue.

echo $title;

if( isset( $title ) ) echo $title;

Or if shortcuts are your thing…

echo isset( $title ) ? $title : '';

The point I’m making here, is that yes- fixing errors is a thing that takes time.  But not so much time that it’s worth a giant pain in the ass like me telling you that I won’t even think about helping you do X Y or Z until I can load your code without seeing 800 of the same undefined variable error 😉  More importantly though, you’re a badass web developer- take pride in your code, and know that what you’ve built IS solid and correct.

Your code will feel better, your clients will feel better, your sites will be more stable, and I won’t hate you anymore! (as long as you comment your code and know how to use the “enter” key that is)