Error_Reporting(E_All) Does Not Produce an Error

error_reporting(E_ALL) does not produce an error

Your file has a syntax error, so your file was not interpreted, so settings were not changed and you have a blank page.

You can separate your file in two:

File index.php

<?php
    ini_set("display_errors", "1");
    error_reporting(E_ALL);
    include 'error.php';

File error.php

<?
    echo('catch this -> ' ;. $thisdoesnotexist);

PHP - error_reporting doesn't work

error_reporting is just telling PHP how verbose the error reporting should be, but you also need to tell it to actually display errors out to the browser by setting

ini_set('display_errors', 1);

php.ini error_reporting set to E_ALL but not working

I was using the @ suppression modifier in front of call_user_func_array in my Router front-end controller class which was resetting error_reporting to 0.

PHP error_reporting either on or off

I would say there is probably another page or script that is being included that is setting error_reporting to a different value. You can call error_reporting() with no args to get the current value. Set it to something and check that the value hasn't changed after including other files.

How do I get PHP errors to display?

This always works for me:

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

However, this doesn't make PHP to show parse errors - the only way to show those errors is to modify your php.ini with this line:

display_errors = on

(if you don't have access to php.ini, then putting this line in .htaccess might work too):

php_flag display_errors 1

php.ini error_reporting recommended production value would show notices?

I guess you wonder why all errors are reported to everyone. But this does not depend on error_reporting only. The missing thing is to check the value of display_errors in the php.ini.

PHP Error Reporting Production vs Development

Quoting the php-production.ini that should have come bundled with your PHP:

; PHP comes packaged with two INI files. One that is recommended to be used
; in production environments and one that is recommended to be used in
; development environments.

; php.ini-production contains settings which hold security, performance and
; best practices at its core. But please be aware, these settings may break
; compatibility with older or less security conscience applications. We
; recommending using the production ini in production and testing environments.

and further

; display_errors
;   Default Value: On
;   Development Value: On
;   Production Value: Off

; display_startup_errors
;   Default Value: Off
;   Development Value: On
;   Production Value: Off

; error_reporting
;   Default Value: E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
;   Development Value: E_ALL
;   Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT

; html_errors
;   Default Value: On
;   Development Value: On
;   Production value: On

; log_errors
;   Default Value: Off
;   Development Value: On
;   Production Value: On

Since you asked for best practise, I suggest you go with that.

php error_reporting() method in the 5.6.3 version

A semicolon is missing at the end of the second line of code

echo $var = 'hex' 

This is the cause of the error and this is a compile error, not a runtime error. Because it cannot be compiled successfully, the script is not started at all. There is no runtime, the script never ran.

There is no way to suppress compile errors. Their purpose is to show the programmer that the script cannot be compiled and why.

Why doesn't PHP report this error?

Background info:

If your error_reporting settings are being setup via function call (not settings files), a syntax error which occurs in the first file being loaded (ex.: index.php) the PHP interpreter can't output the error.

If you have a very simple index.php file which includes the file with the fatal syntax error in it, then the PHP interpreter will be able to output the error.

This is a "known limitation" of the PHP interpreter caused by the fact that most interpreters need to read the file in two passes first to pick up the tokens and then to assess if the tokens correctly represent the language's grammar (allowed order of tokens).

Actually running the code happens after the interpreter finishes these two passes successfully; if it doesn't then all the information the interpreter has is that a syntax error occurred, it doesn't know that you have set error_reporting to some level or another because it considers whatever it read from the file to be "invalid syntax" so it can't run it.

Concrete info:

Since you're using a new syntactic language construct that PHP 5.4 provides but PHP 5.3 doesn't, the legitimate PHP 5.4 construct becomes a syntax error in PHP 5.3.

Having a call to error_reporting in the same file as the syntax error means the function call will not occur and the error level will not be correctly set.

Workaround:

Set your error level by declaring it in your php.ini file or .htaccess file.

---

Related Topics