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

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

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


当前回答

使用@inexistent_function_call ();将导致解释器安静地停止并中止脚本解析。您应该检查无效的函数,并尽量不要使用错误抑制操作符(@ char)

其他回答

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

您可以在要调试的文件中包含以下行:

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

这将覆盖PHP .ini中的默认设置,这只会使PHP向日志报告错误。

我用这样的方法解决了我的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页面,如下所示。

完成:)

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

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.

使用@inexistent_function_call ();将导致解释器安静地停止并中止脚本解析。您应该检查无效的函数,并尽量不要使用错误抑制操作符(@ char)