我经常会尝试运行PHP脚本,然后得到一个空白屏幕。没有错误信息;只有一个空屏幕。原因可能是一个简单的语法错误(错误的括号,缺少分号),或者函数调用失败,或者完全是其他原因。
很难找出哪里出了问题。我最终注释掉了代码,到处输入“echo”语句,等等,试图缩小问题的范围。但肯定有更好的办法,对吧?
是否有一种方法可以让PHP像Java那样产生有用的错误消息?
我经常会尝试运行PHP脚本,然后得到一个空白屏幕。没有错误信息;只有一个空屏幕。原因可能是一个简单的语法错误(错误的括号,缺少分号),或者函数调用失败,或者完全是其他原因。
很难找出哪里出了问题。我最终注释掉了代码,到处输入“echo”语句,等等,试图缩小问题的范围。但肯定有更好的办法,对吧?
是否有一种方法可以让PHP像Java那样产生有用的错误消息?
当前回答
要打开完整的错误报告,请在脚本中添加以下内容:
error_reporting(E_ALL);
这甚至会导致出现最小的警告。还有,以防万一:
ini_set('display_errors', '1');
将强制显示错误。这应该在生产服务器中关闭,但在开发时不可以。
其他回答
error_reporting(E_ALL | E_STRICT);
并在php.ini中打开显示错误
我用这样的方法解决了我的500个问题:
A.检查php.ini参数
php.ini >> error_reporting = E_ALL | E_STRICT php.ini >> display_errors = On php.ini >> display_startup_errors =关闭
B.更新IIS管理器参数
IIS管理器>>错误页面>> 500 >>编辑功能设置>>详细错误
在这一步中,您将得到500个这样的错误,并且没有加载HTML。
IIS管理>> FastCGI设置>> php-cgi.exe >>标准错误模式>> IgnoreAndReurn200
在这一步中,您可以看到包含PHP错误的HTML页面,如下所示。
完成:)
“错误”是开发人员了解他们的错误并解决它们以使系统完美工作的最有用的东西。
PHP提供了一些更好的方法来了解开发人员为什么以及他们的代码在哪里出错,因此通过了解这些错误,开发人员可以在许多方面改进他们的代码。
最好的方法是在脚本顶部写以下两行来获得所有错误消息:
error_reporting(E_ALL);
ini_set("display_errors", 1);
在IDE中使用xdebug等调试器工具的另一种方法。
这个答案是由冗余部门为您带来的。
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.
你也可以像这样在终端(命令行)运行文件:
这将运行您的代码,并为您提供与在error.log中看到的任何错误相同的输出。它提到了错误和行号。