我经常会尝试运行PHP脚本,然后得到一个空白屏幕。没有错误信息;只有一个空屏幕。原因可能是一个简单的语法错误(错误的括号,缺少分号),或者函数调用失败,或者完全是其他原因。

很难找出哪里出了问题。我最终注释掉了代码,到处输入“echo”语句,等等,试图缩小问题的范围。但肯定有更好的办法,对吧?

是否有一种方法可以让PHP像Java那样产生有用的错误消息?


当前回答

这是一个加载配置与运行时配置的问题

重要的是要认识到在编译或解析步骤中会发生语法错误或解析错误,这意味着PHP甚至在有机会执行任何代码之前就会退出。因此,如果你在运行时修改PHP的display_errors配置(这包括在代码中使用ini_set到使用.htaccess,这是一个运行时配置文件),那么只有默认加载的配置设置在起作用。

如何在开发中始终避免WSOD

为了避免WSOD,您需要确保加载的配置文件具有display_errors,并将error_reporting设置为-1(这相当于E_ALL,因为它确保无论您运行的是哪个版本的PHP,所有位都是打开的)。不要硬编码E_ALL的常量值,因为该值在不同版本的PHP之间可能会发生变化。

Loaded configuration is either your loaded php.ini file or your apache.conf or httpd.conf or virtualhost file. Those files are only read once during the startup stage (when you first start apache httpd or php-fpm, for example) and only overridden by runtime configuration changes. Making sure that display_errors = 1 and error_reporting = -1 in your loaded configuration file ensures that you will never see a WSOD regardless of syntax or parse error that occur before a runtime change like ini_set('display_errors', 1); or error_reporting(E_ALL); can take place.

如何找到你(php.ini)加载的配置文件

要定位您加载的配置文件,只需用以下代码创建一个新的PHP文件…

<?php
phpinfo();

然后将浏览器指向那里,查看已加载配置文件和已解析的附加.ini文件,它们通常位于phpinfo()的顶部,并将包括所有已加载配置文件的绝对路径。

如果你看到(none)而不是文件,这意味着你在配置文件(php.ini)路径中没有php.ini。因此,您可以从这里下载与PHP捆绑的库存PHP .ini,并将其复制到您的配置文件路径作为PHP .ini,然后确保您的PHP用户有足够的权限从该文件读取。您需要重新启动httpd或php-fpm来加载它。记住,这是PHP源代码附带的开发PHP .ini文件。所以请不要在生产中使用它!


只是不要在生产中这样做

这确实是在开发过程中避免WSOD的最佳方法。有人建议你把ini_set('display_errors', 1);或error_reporting (E_ALL);在你的PHP脚本顶部或使用.htaccess,就像你在这里所做的,不会帮助你避免WSOD当语法或解析错误发生时(就像你在这里的情况),如果你加载的配置文件已经display_errors关闭。

Many people (and stock installations of PHP) will use a production-ini file that has display_errors turned off by default, which typically results in this same frustration you've experienced here. Because PHP already has it turned off when it starts up, then encounters a syntax or parse error, and bails with nothing to output. You expect that your ini_set('display_errors',1); at the top of your PHP script should have avoided that, but it won't matter if PHP can't parse your code because it will never have reached the runtime.

其他回答

我总是在php脚本的最顶部使用这种语法。

ini_set('error_reporting', E_ALL);
ini_set('display_errors', 'On');  //On or Off

下面的代码应该显示所有错误:

<?php

// ----------------------------------------------------------------------------------------------------
// - Display Errors
// ----------------------------------------------------------------------------------------------------
ini_set('display_errors', 'On');
ini_set('html_errors', 0);

// ----------------------------------------------------------------------------------------------------
// - Error Reporting
// ----------------------------------------------------------------------------------------------------
error_reporting(-1);

// ----------------------------------------------------------------------------------------------------
// - Shutdown Handler
// ----------------------------------------------------------------------------------------------------
function ShutdownHandler()
{
    if(@is_array($error = @error_get_last()))
    {
        return(@call_user_func_array('ErrorHandler', $error));
    };

    return(TRUE);
};

register_shutdown_function('ShutdownHandler');

// ----------------------------------------------------------------------------------------------------
// - Error Handler
// ----------------------------------------------------------------------------------------------------
function ErrorHandler($type, $message, $file, $line)
{
    $_ERRORS = Array(
        0x0001 => 'E_ERROR',
        0x0002 => 'E_WARNING',
        0x0004 => 'E_PARSE',
        0x0008 => 'E_NOTICE',
        0x0010 => 'E_CORE_ERROR',
        0x0020 => 'E_CORE_WARNING',
        0x0040 => 'E_COMPILE_ERROR',
        0x0080 => 'E_COMPILE_WARNING',
        0x0100 => 'E_USER_ERROR',
        0x0200 => 'E_USER_WARNING',
        0x0400 => 'E_USER_NOTICE',
        0x0800 => 'E_STRICT',
        0x1000 => 'E_RECOVERABLE_ERROR',
        0x2000 => 'E_DEPRECATED',
        0x4000 => 'E_USER_DEPRECATED'
    );

    if(!@is_string($name = @array_search($type, @array_flip($_ERRORS))))
    {
        $name = 'E_UNKNOWN';
    };

    return(print(@sprintf("%s Error in file \xBB%s\xAB at line %d: %s\n", $name, @basename($file), $line, $message)));
};

$old_error_handler = set_error_handler("ErrorHandler");

// other php code

?>

使用此代码生成空白页的唯一方法是在关闭处理程序中出现错误时。我复制并粘贴了这个从我自己的cms没有测试,但我相信它工作。

这是一个加载配置与运行时配置的问题

重要的是要认识到在编译或解析步骤中会发生语法错误或解析错误,这意味着PHP甚至在有机会执行任何代码之前就会退出。因此,如果你在运行时修改PHP的display_errors配置(这包括在代码中使用ini_set到使用.htaccess,这是一个运行时配置文件),那么只有默认加载的配置设置在起作用。

如何在开发中始终避免WSOD

为了避免WSOD,您需要确保加载的配置文件具有display_errors,并将error_reporting设置为-1(这相当于E_ALL,因为它确保无论您运行的是哪个版本的PHP,所有位都是打开的)。不要硬编码E_ALL的常量值,因为该值在不同版本的PHP之间可能会发生变化。

Loaded configuration is either your loaded php.ini file or your apache.conf or httpd.conf or virtualhost file. Those files are only read once during the startup stage (when you first start apache httpd or php-fpm, for example) and only overridden by runtime configuration changes. Making sure that display_errors = 1 and error_reporting = -1 in your loaded configuration file ensures that you will never see a WSOD regardless of syntax or parse error that occur before a runtime change like ini_set('display_errors', 1); or error_reporting(E_ALL); can take place.

如何找到你(php.ini)加载的配置文件

要定位您加载的配置文件,只需用以下代码创建一个新的PHP文件…

<?php
phpinfo();

然后将浏览器指向那里,查看已加载配置文件和已解析的附加.ini文件,它们通常位于phpinfo()的顶部,并将包括所有已加载配置文件的绝对路径。

如果你看到(none)而不是文件,这意味着你在配置文件(php.ini)路径中没有php.ini。因此,您可以从这里下载与PHP捆绑的库存PHP .ini,并将其复制到您的配置文件路径作为PHP .ini,然后确保您的PHP用户有足够的权限从该文件读取。您需要重新启动httpd或php-fpm来加载它。记住,这是PHP源代码附带的开发PHP .ini文件。所以请不要在生产中使用它!


只是不要在生产中这样做

这确实是在开发过程中避免WSOD的最佳方法。有人建议你把ini_set('display_errors', 1);或error_reporting (E_ALL);在你的PHP脚本顶部或使用.htaccess,就像你在这里所做的,不会帮助你避免WSOD当语法或解析错误发生时(就像你在这里的情况),如果你加载的配置文件已经display_errors关闭。

Many people (and stock installations of PHP) will use a production-ini file that has display_errors turned off by default, which typically results in this same frustration you've experienced here. Because PHP already has it turned off when it starts up, then encounters a syntax or parse error, and bails with nothing to output. You expect that your ini_set('display_errors',1); at the top of your PHP script should have avoided that, but it won't matter if PHP can't parse your code because it will never have reached the runtime.

我推荐Nette Tracy来更好地可视化PHP中的错误和异常:

这个答案是由冗余部门为您带来的。

ini_set() / php.ini / .htaccess / .user.ini The settings display_errors and error_reporting have been covered sufficiently now. But just to recap when to use which option: ini_set() and error_reporting() apply for runtime errors only. php.ini should primarily be edited for development setups. (Webserver and CLI version often have different php.ini's) .htaccess flags only work for dated setups (Find a new hoster! Well managed servers are cheaper.) .user.ini are partial php.ini's for modern setups (FCGI/FPM) And as crude alternative for runtime errors you can often use: set_error_handler("var_dump"); // ignores error_reporting and `@` suppression error_get_last() Can be used to retrieve the last runtime notice/warning/error, when error_display is disabled. $php_errormsg Is a superlocal variable, which also contains the last PHP runtime message. isset() begone! I know this will displease a lot of folks, but isset and empty should not be used by newcomers. You can add the notice suppression after you verified your code is working. But never before. A lot of the "something doesn't work" questions we get lately are the result of typos like: if(isset($_POST['sumbit'])) # ↑↑ You won't get any useful notices if your code is littered with isset/empty/array_keys_exists. It's sometimes more sensible to use @, so notices and warnings go to the logs at least. assert_options(ASSERT_ACTIVE|ASSERT_WARNING); To get warnings for assert() sections. (Pretty uncommon, but more proficient code might contain some.) PHP7 requires zend.assertions=1 in the php.ini as well. declare(strict_types=1); Bending PHP into a strictly typed language is not going to fix a whole lot of logic errors, but it's definitely an option for debugging purposes. PDO / MySQLi And @Phil already mentioned PDO/MySQLi error reporting options. Similar options exist for other database APIs of course. json_last_error() + json_last_error_msg For JSON parsing. preg_last_error() For regexen. CURLOPT_VERBOSE To debug curl requests, you need CURLOPT_VERBOSE at the very least. shell/exec() Likewise will shell command execution not yield errors on its own. You always need 2>&1 and peek at the $errno.