Parse errors are not displayed

问题:

I want PHP to display parse errors on screen. What I get instead is a blank page. Nothing gets written to server's error log file.

My setup: PHP5.2.9/IIS 6 (not Apache!).

My PHP.INI:

error_reporting=E_STRICT
display_errors = On
display_startup_errors = On
log_errors = On
error_log = "C:\Program Files\Zend\ZendServer\logs\php_error.log"

How do I get parse or fatal errors to be either logged or shown on screen?

Thanks, Temuri

UPDATE: After playing with different switches it looks to be an IIS specific problem. ANY IDEAS FOLKS?

回答1:

Setting error level in php file itself does not resolve the problem here because the file itself cannot be parsed !!

You need to change error_reporting line in your php.ini as follows:

error_reporting = E_ALL

BTW: There are some examples in php.ini file about what to do to display which type of error messages.

Good luck,

mcemoz

回答2:

Apache doesn't always like to report parsing errors either. From the command line, run

php -l <file>

The -l switch tells PHP to check file syntax. See the man page.

回答3:

E_STRICT is not included in E_ALL (until PHP 6). If you want to keep getting E_STRICT

In php.ini:

error_reporting = E_ALL | E_STRICT

At runtime:

error_reporting( E_ALL | E_STRICT );

You'll need to set the error reporting level (and display_errors) in php.ini to see syntax errors. If PHP encounters a syntax error, the runtime doesn't get executed, so setting at runtime won't work. (See the display_errors link.)

回答4:

You can verify the script syntax with this command in terminal:

php -l path/to/file.php

Personally, I added this line to my ~/.bash_profile file so I can easily run php -l on all files in the current working directory:

phpl() { for i in *.php; do php -l $i; done }

If you're really hardcore, you can even run your app from the command line. You'll have a much better chance of seeing compile-time errors, and it's just kinda cool.

You can use the $argv variable to get the first argument, $argv[1], then use that as the request.

<?php
// show those errors!
error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', 1);

// simulate a web server request
$request = '/' . isset($argv[1]) ? ltrim($argv[1], '/') : '/';
$_SERVER['PATH_INFO'] = $_SERVER['REQUEST_URI'] = $request;

Then you can run your script via command line. This would be the equivalent of visiting: your-webapp.com/request/uri/here

php /path/to/script.php request/uri/here

Here is a more comprehensive example for running CodeIgniter via command line. It should work for many other frameworks too: http://phpstarter.net/2008/12/run-codeigniter-from-the-command-line-ssh/

回答5:

As Rasmus Lerdorf suggests, always use error_reporting(-1) on development server.

回答6:

Re: Blank screen of php death death, I discovered that setting

php_value error_reporting "E_ALL" or php_value error_reporting 8192

in .htaccess on my Windows 7, Wampserver w/ apache 2.2.4 and php 5.3.13 are sure ways to get the blank php error screen -- today, June 3, 2014. These htaccess lines DO set the desires value in phpinfo(), but the display of the errors happens only when the line is commented out (not used) in htaccess.

BUT... the next minute I discover that

php_value error_reporting 8191

DOES set the phpinfo() value AND also allows display of the error messages to the browser! D'oh! It must be an integer and also apparently a particular or valid integer, and not just a large enough integer!

回答7:

If you're using Zend Framework (v1) and you're using the Autoloader, the following code will prevent parse errors from being displayed:

self::$Autoloader->suppressNotFoundWarnings(true);

See the following answer for more details:

Display php errors when using Zend framework

回答8:

Try this.

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