我经常会尝试运行PHP脚本,然后得到一个空白屏幕。没有错误信息;只有一个空屏幕。原因可能是一个简单的语法错误(错误的括号,缺少分号),或者函数调用失败,或者完全是其他原因。
很难找出哪里出了问题。我最终注释掉了代码,到处输入“echo”语句,等等,试图缩小问题的范围。但肯定有更好的办法,对吧?
是否有一种方法可以让PHP像Java那样产生有用的错误消息?
我经常会尝试运行PHP脚本,然后得到一个空白屏幕。没有错误信息;只有一个空屏幕。原因可能是一个简单的语法错误(错误的括号,缺少分号),或者函数调用失败,或者完全是其他原因。
很难找出哪里出了问题。我最终注释掉了代码,到处输入“echo”语句,等等,试图缩小问题的范围。但肯定有更好的办法,对吧?
是否有一种方法可以让PHP像Java那样产生有用的错误消息?
当前回答
要持久保存并使其符合要求,可以编辑php.ini文件。它通常存储在/etc/php.ini或/etc/php/php.ini中,但更多的本地php.ini可能会覆盖它,这取决于主机提供商的设置指南。检查phpinfo()文件顶部的已加载配置文件,以确保最后加载哪个文件。
在该文件中搜索display_errors。应该只有3个实例,其中2个是注释的。
将未注释的行更改为:
display_errors = stdout
其他回答
PHP配置
php.ini中的2个条目指示错误的输出:
display_errors error_reporting
在生产中,display_errors通常设置为Off(这是一件好事,因为在生产站点中错误显示通常是不可取的!)
但是,在开发中,应该将其设置为On,以便显示错误。检查!
error_reporting(从PHP 5.3开始)默认设置为E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED(意思是,除了通知、严格标准和弃用通知之外的所有内容都会显示)。当不确定时,将其设置为E_ALL以显示所有错误。检查!
哇哇!没有检查!我不能改变我的php.ini!
真遗憾。通常共享主机不允许更改它们的php.ini文件,因此,遗憾的是,这个选项是不可用的。但是不要害怕!我们还有其他选择!
运行时配置
在所需的脚本中,我们可以在运行时更改php.ini条目!这意味着,它将在脚本运行时运行!甜蜜的!
error_reporting(E_ALL);
ini_set("display_errors", "On");
这两行代码与上面修改php.ini条目的效果相同!太棒了!
我仍然得到一个空白页/500错误!
这意味着脚本甚至还没有运行!这通常发生在语法错误的时候!
由于语法错误,脚本甚至无法进入运行时。它在编译时失败,这意味着它将使用php.ini中的值,如果没有更改,可能不允许显示错误。
错误日志
此外,PHP在默认情况下会记录错误。在共享主机中,它可能位于专用文件夹中,也可能位于与该脚本相同的文件夹中。
如果您可以访问php.ini,您可以在error_log条目下找到它。
你需要从PHP中获取有用错误的两行关键代码是:
ini_set('display_errors',1);
error_reporting(E_ALL);
正如其他贡献者所指出的那样,出于安全原因,这些功能在默认情况下是关闭的。作为一个有用的技巧——当你设置你的网站时,为你的不同环境做一个切换是很方便的,这样在你的本地和开发环境中,这些错误默认是打开的。这可以通过以下代码实现(理想情况下是在index.php或配置文件中,这样从一开始就处于活动状态):
switch($_SERVER['SERVER_NAME'])
{
// local
case 'yourdomain.dev':
// dev
case 'dev.yourdomain.com':
ini_set('display_errors',1);
error_reporting(E_ALL);
break;
//live
case 'yourdomain.com':
//...
break;
}
对于语法错误,您需要在php.ini中启用错误显示。默认情况下,这些是关闭的,因为您不希望“客户”看到错误消息。查看PHP文档中关于error_reporting和display_errors这两个指令的信息。Display_errors可能是您想要更改的。如果你不能修改php.ini,你也可以在。htaccess文件中添加以下代码:
php_flag display_errors on
php_value error_reporting 2039
您可以考虑在您的PHP版本中使用E_ALL的值(如Gumbo所提到的)用于error_reporting以获取所有错误。更多信息
(1)您可以检查错误日志文件,因为它将有所有的错误(除非日志记录已被禁用)。(2)添加以下两行代码将帮助您调试非语法错误:
error_reporting(-1);
ini_set('display_errors', 'On');
另一种选择是使用编辑器,当你打字时检查错误,如PhpEd。PhpEd还提供了一个调试器,可以提供更详细的信息。(PhpEd调试器与xdebug非常相似,并直接集成到编辑器中,因此您可以使用一个程序来完成所有工作。)
卡特曼的链接也很好:http://www.ibm.com/developerworks/library/os-debug/
这个答案是由冗余部门为您带来的。
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_reporting(E_ALL | E_STRICT);
ini_set('display_errors', 1);
ini_set('html_errors', 1);
此外,使用xdebug可以获得更详细的信息。