It should be noted that this setting DOES NOT suppress the error. Even if the directive is set to ‘Off’ (do not display errors) errors which occur in a script are still triggered and will be processed by the error handler.

</IMPORTANT>

 
PHP does not offer a special display_errors function, but by using the ini_set() function we can control the setting of this directive within our script. The function signature looks like this:

string ini_set ( string $varname , string $newvalue )

blah, blah

The configuration option I would like to address in this article is, of course, error_reporting.

Let’s start digging.

error_reporting

The error_reporting directive (within the PHP ini file) allows you to set the level of errors reported by PHP. By default this is set to ‘E_ALL & ~E_NOTICE’. This ‘tells’ PHP to report all errors, except Notices.

PHP provides a built-in function for getting and setting the error_reporting level: error_reporting(). The function signature looks like this:

int error_reporting ([ int $level ] )

The function accepts one optional argument, a new error reporting level, and returns the old error reporting level. Although the signiture shows that the function accepts an integer, the new level sent can be represented by a predefined constant. In fact it is recommended that you use the predefined constants to ensure future compatibility.

The available constants can be used in combination to build up a bitmask; the bitmask tells PHP which errors to report and which to suppress. Since these constants are actually bitmasks, you will need to use bitwise operators when combining them.

An example of the error reporting setting I use in development is:

$old_setting = error_reporting(E_ALL | E_STRICT);

From the predefined constants chart the setting E_ALL equates to the integer 30719 and means:

All errors and warnings, as supported, except of level E_STRICT in PHP < 6.

From the predefined constants chart the setting E_STRICT equates to the integer 2048 and means:

Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.

So basically, this tell PHP to report all errors, notices, and messages generated at the E_STRICT level.

Back to the code…

The variable $old_setting will now be set to: 6135, the default setting for error reporting (using the predefined constants again that would be: E_ALL & ~E_NOTICE).

A small code example:

<?php
//get the current error reporting setting
$current_setting = error_reporting();

//check if error reporting is set to E_ALL | E_STRICT
if (8191 != $current_setting) {
    //not set to E_ALL | E_STRICT make it so
    error_reporting(E_ALL | E_STRICT);
}

//display new error reporting setting

echo error_reporting(); //displays 8191
?>

A more useful example would be to change the error_reporting setting based on the environment the script is being run in.

Let’s say you have a configuration file which defines the constant ‘ENV’, this can be set to ‘production’ (live site) or ‘development’. If the script is run in production then we want to use ‘E_ALL & ~E_NOTICE’ (default), but when running in development we want to use E_ALL | E_STRICT.

config.php:

<?php

//define enviroment
define('ENV', 'development');

Script File:

<?php

//load configuration file
require_once('config.php');

//check ENV constant to see if running in development
if ('development' == ENV) {
    //running in development so change default setting
    error_reporting(E_ALL | E_STRICT);
    //now all errors, notices, and suggestions will be reported
}

That’s it! I’m sure you can see how useful this function can be.

Side Note: If you are unsure what a bitmask is or are unfamiliar with bitwise operators, you may want to checkout this post from joestump.net.

When I first started learning about errors and error handling I found numerous tutorials on the topic, but none that provided a complete resource on the subject. This is understandable; since the topic is so broad one tutorial would not only be extremely long, it might also seem overwhelming to someone who just started learning about the topic. This is also the reason it would make a great topic to cover on a blog, where a series of posts can be created, each building on the information presented in the previous post ending with a comprehensive  resource. (OK, comprehensive maybe a little strong but hopefully it will be close.)

The intended outline for the series is:

Resource Information

• Error Messages Deciphered (Revised)
• Error Reporting
• Displaying Errors
• Error Logging
• Backtrace Functions
• Triggering Errors
• Understanding Exceptions

Implementation

• Creating A Custom Error Handler
• Utilizing Exceptions
• Creating an Exception Hierarchy

Putting it all together

• Error Handling Strategies

I completely disagree with this point of view. If I write code which is not intended to generate Notices, then as the developer I want to know if and when Notices are being generated in any environment.

Notices are very helpful in tracking down logical errors or bugs, which cause the script not to function as expected. In PHP they are normally generated when using a previously undeclared variable. Technically speaking there is nothing wrong with this in PHP, other programming languages are not so forgiving.

I personally started declaring all variables when I began to focus on the security implications of using undeclared variables (we’ll save that information for another post). After getting in the habit I found that I was able find logical errors during development even before I noticed that a bug existed. After realizing this, I now never release code which is know to generate notices. I have also started setting error reporting to E_ALL in all environments.

I understand that this is not feasible for everyone. It may not be possible in a professional working environment because of dealing with legacy code. Another issue could arise if you use third-party code which has not subscribed to this way of thinking. Although personally, I feel this is not an excuse there is no reason you can’t get in there and ‘fix’ their script.

A word of warning

I was once hired to fix numerous bugs on a site, all were a fairly obvious fix, but one in particular had me stumped. I turned on notices when attempting to debug the problem and ended up with an error log that contained over 250 notices for every page load. Since this was a dev environment setup by the client for my use, it was no big deal, but if it were a heavily trafficked live site, there could have been some serious implications.