jump to navigation

How to enable error reporting in php? October 21, 2010

Posted by Tournas Dimitrios in PHP.

In Shared Web hosting, normally we won’t  have access to the root folder php.ini file for changing any settings. Some settings can be changed by putting another php.ini in our required folder (If PHP is compiled as a CGI binary) or even deploy a .httaccess file (if PHP is installed as an Apache module) . In this case the value will be taken from php.ini  (or .httaccess ) located in our folder instead of from the root folder.
But it will not be applicable for all the settings. Some settings can not be overridden.
Say for example, display of error messages in the browser will be disabled by default in all production environments. But we may need to see the error message if our webpage is not working properly. We can not ask the shared web hosting company to turn on the error message. Because it will affect other people websites also. To avoid this issue, the below code can be placed in the php file for enabling the error message display for the particular page. PHP offers us a dozen of Error Handling Functions , read more on the official website.

//or if you only want to see Warning Messages and not Notice Messages:
//and if you just want all Error Reporting off, simply use this:
//To do this in the .htaccess use:
php_flag display_errors on
php_value error_reporting 7

Setting the Desired Error Sensitivity Level :

The error_reporting directive determines the reporting sensitivity level. Sixteen separate levels are available, and any combination of these levels is valid. See Table below for a complete list of these levels.
Note that each level is inclusive of all levels below it. For example, the E_ALL level reports any messages from the 15 levels below it in the table.

Value Constant Description
1 E_ERROR Fatal run-time errors. Execution of the script is halted
2 E_WARNING Non-fatal run-time errors. Execution of the script is not halted
4 E_PARSE Compile-time parse errors. Parse errors should only be generated by the parser.
8 E_NOTICE Run-time notices. The script found something that might be an error, but could also happen when running a script normally
16 E_CORE_ERROR Fatal errors that occur during PHP’s initial startup.
32 E_CORE_WARNING Non-fatal run-time errors. This occurs during PHP’s initial startup.
256 E_USER_ERROR Fatal user-generated error. This is like an E_ERROR set by the programmer using the PHP function trigger_error()
512 E_USER_WARNING Non-fatal user-generated warning. This is like an E_WARNING set by the programmer using the PHP function trigger_error()
1024 E_USER_NOTICE User-generated notice. This is like an E_NOTICE set by the programmer using the PHP function trigger_error()
2048 E_STRICT Run-time notices. Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.
4096 E_RECOVERABLE_ERROR Catchable fatal error. This is like an E_ERROR but can be caught by a user defined handle (see also set_error_handler())
8191 E_ALL All errors and warnings, except level E_STRICT (E_STRICT will be part of E_ALL as of PHP 6.0)

During the development stage, you’ll likely want all errors to be reported. Therefore, consider setting the directive like this:
error_reporting = E_ALL & E_STRICT
I’ve included E_STRICT alongside E_ALL because in PHP versions prior to the forthcoming version 6, E_ALL does not include E_STRICT-related errors.  However, suppose that you were only concerned about fatal run-time, parse, and core errors. You
could use logical operators to set the directive as follows:
error_reporting = E_ERROR | E_PARSE | E_CORE_ERROR
As a final example, suppose you want all errors reported except for those of level E_USER_WARNING:
error_reporting = E_ALL & ~E_USER_WARNING
Ultimately, the goal is to stay well-informed about your application’s ongoing issues without becoming so inundated with information that you quit looking at the logs. Spend some time experimenting with the various levels during the development process, at least until you’re well aware of the various types of reporting data that each configuration provides.

Displaying Errors to the Browser :
Enabling the display_errors directive results in the display of any errors meeting the criteria defined by error_reporting. You should have this directive enabled only during testing and keep it disabled when the site is live. The display of such messages is not only likely to further confuse the end user but could also provide more information about your application/server than you might like to make available. For example, suppose you are using a flat file to store newsletter subscriber e-mail addresses. Due to a permissions misconfiguration, the application could not write to the file. Yet rather than catch the error and offer a user-friendly response, you instead opt to allow PHP to report the matter to the end-user , so be carefull .

Final note : This article was mainly focused on error-reporting  from the perspective of Configuration directives .PHP offers us also other mechanisms to handle – report  errors , vs . Error logging and Exception handling.



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s