我经常会尝试运行PHP脚本,然后得到一个空白屏幕。没有错误信息;只有一个空屏幕。原因可能是一个简单的语法错误(错误的括号,缺少分号),或者函数调用失败,或者完全是其他原因。
很难找出哪里出了问题。我最终注释掉了代码,到处输入“echo”语句,等等,试图缩小问题的范围。但肯定有更好的办法,对吧?
是否有一种方法可以让PHP像Java那样产生有用的错误消息?
我经常会尝试运行PHP脚本,然后得到一个空白屏幕。没有错误信息;只有一个空屏幕。原因可能是一个简单的语法错误(错误的括号,缺少分号),或者函数调用失败,或者完全是其他原因。
很难找出哪里出了问题。我最终注释掉了代码,到处输入“echo”语句,等等,试图缩小问题的范围。但肯定有更好的办法,对吧?
是否有一种方法可以让PHP像Java那样产生有用的错误消息?
当前回答
打开错误报告是正确的解决方案,但是它似乎不会在打开它的程序中生效,而只会在随后包含的程序中生效。
因此,我总是创建一个文件/程序(我通常称之为“genwrap.php”),它的代码本质上与这里流行的解决方案相同。打开错误报告),然后它还包括我实际想要调用的页面。
实现这个调试有两个步骤;
首先,创建genwrap.php,然后把下面的代码放进去:
<?php
error_reporting(-1);
ini_set('display_errors', 'On');
include($_REQUEST['page']);
?>
第二,将你想要调试的程序/页面的链接改为通过genwrap.php,
例如:改变:
$.ajax('dir/pgm.php?param=val').done(function(data) { /* ... */
to
$.ajax('dir/genwrap.php?page=pgm.php¶m=val').done(function(data) { /* ... */
其他回答
我不知道它是否有帮助,但这里是我的php项目的标准配置文件的一部分。我倾向于不太依赖apache配置,即使是在我自己的服务器上。
我从来没有遇到过错误消失的问题,所以也许这里的一些东西会给你一个想法。
编辑以显示APPLICATON_LIVE
/*
APPLICATION_LIVE will be used in process to tell if we are in a development or production environment. It's generally set as early as possible (often the first code to run), before any config, url routing, etc.
*/
if ( preg_match( "%^(www.)?livedomain.com$%", $_SERVER["HTTP_HOST"]) ) {
define('APPLICATION_LIVE', true);
} elseif ( preg_match( "%^(www.)?devdomain.net$%", $_SERVER["HTTP_HOST"]) ) {
define('APPLICATION_LIVE', false);
} else {
die("INVALID HOST REQUEST (".$_SERVER["HTTP_HOST"].")");
// Log or take other appropriate action.
}
/*
--------------------------------------------------------------------
DEFAULT ERROR HANDLING
--------------------------------------------------------------------
Default error logging. Some of these may be changed later based on APPLICATION_LIVE.
*/
error_reporting(E_ALL & ~E_STRICT);
ini_set ( "display_errors", "0");
ini_set ( "display_startup_errors", "0");
ini_set ( "log_errors", 1);
ini_set ( "log_errors_max_len", 0);
ini_set ( "error_log", APPLICATION_ROOT."logs/php_error_log.txt");
ini_set ( "display_errors", "0");
ini_set ( "display_startup_errors", "0");
if ( ! APPLICATION_LIVE ) {
// A few changes to error handling for development.
// We will want errors to be visible during development.
ini_set ( "display_errors", "1");
ini_set ( "display_startup_errors", "1");
ini_set ( "html_errors", "1");
ini_set ( "docref_root", "http://www.php.net/");
ini_set ( "error_prepend_string", "<div style='color:red; font-family:verdana; border:1px solid red; padding:5px;'>");
ini_set ( "error_append_string", "</div>");
}
这个答案是由冗余部门为您带来的。
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.
要持久保存并使其符合要求,可以编辑php.ini文件。它通常存储在/etc/php.ini或/etc/php/php.ini中,但更多的本地php.ini可能会覆盖它,这取决于主机提供商的设置指南。检查phpinfo()文件顶部的已加载配置文件,以确保最后加载哪个文件。
在该文件中搜索display_errors。应该只有3个实例,其中2个是注释的。
将未注释的行更改为:
display_errors = stdout
您可以在要调试的文件中包含以下行:
error_reporting(E_ALL);
ini_set('display_errors', '1');
这将覆盖PHP .ini中的默认设置,这只会使PHP向日志报告错误。
可以通过注册钩子来显示最后一个错误或警告。
function shutdown(){
var_dump(error_get_last());
}
register_shutdown_function('shutdown');
将此代码添加到index.php的开头将有助于调试问题。