开发时推荐的 error_reporting() 设置是什么？ E_STRICT 呢？答案

【问题标题】：What is the recommended error_reporting() setting for development? What about E_STRICT?开发时推荐的 error_reporting() 设置是什么？ E_STRICT 呢？
【发布时间】：2010-09-09 15:28:48
【问题描述】：

我通常使用E_ALL 来查看 PHP 可能对我的代码所说的任何内容以尝试改进它。

我刚刚注意到一个错误常量E_STRICT，但从未使用或听说过它，这是用于开发的好设置吗？手册说：

运行时通知。启用让 PHP 建议对您的代码进行更改，这将确保您的代码的最佳互操作性和前向兼容性。

所以我想知道我是使用最好的error_reporting 级别和E_ALL 还是将它与E_STRICT 一起使用是最好的？还是我还没有学习其他组合？

【问题讨论】：

标签： php error-reporting

【解决方案1】：

ini_set("display_errors","2"); ERROR_REPORTING(E_ALL);

【讨论】：

好的，PHP 的函数名不区分大小写，但您应该按照应有的方式使用它（例如error_reporting( E_ALL | E_STRICT )，其中函数名不使用大写字母）。顺便说一句，在低于 5.4 的 PHP 版本中，E_ALL 不包含 E_STRICT。

【解决方案2】：

在我看来，您在开发阶段设置的错误报告级别越高越好。

在实时环境中，您需要稍微（但只是稍微）减少的集合，但您希望它们记录在用户看不到的地方（我更喜欢 syslog）。

http://php.net/error_reporting

E_ALL | E_STRICT 用于 5.2.0 之前的 PHP 开发。

5.2 引入了E_RECOVERABLE_ERROR，5.3 引入了E_DEPRECATED 和E_USER_DEPRECATED。如果您正在运行其中一个版本，您可能需要打开它们。

如果您想使用幻数，您可以将error_reporting 的值设置为2^n-1 的某个相当高的值——比如16777215，这实际上只会打开1..n 之间的所有位。但我不认为使用幻数是个好主意...

在我看来，PHP 让E_ALL 不是全部，这让我有点失落了。但显然它将在 PHP 6 中修复...

【讨论】：

【解决方案3】：

在 PHP 5 中，E_STRICT 涵盖的东西没有被E_ALL 涵盖，因此要获得最多的信息，您需要将它们组合起来：

 error_reporting(E_ALL | E_STRICT);

在 PHP 5.4 中，E_STRICT 将包含在 E_ALL 中，因此您可以只使用 E_ALL。

你也可以使用

error_reporting(-1);

这将始终启用 all 错误。哪个在语义上更正确：

error_reporting(~0);

【讨论】：

请注意，对于 PHP >= 5.4，E_STRICT 包含在 E_ALL 中
@hakre，我不确定我是否理解您对此答案的编辑。您显然是在暗示在“深奥系统”上，-1 != ~0.这些深奥的系统是什么，它们真的存在吗？我猜 PHP 的整数是否以 C 编译器用于编译 PHP 使用的任何格式存储是正确的，并且您正在考虑一个假设场景，其中有人在一个补码 C 编译器上编译 PHP？无论如何，简单地修改 Gordon 的代码 sn-p 不是比留下“实际上，最后一段是错误的”编辑更好吗？
-1 是一个数字，- 一个数字运算符。根据处理负整数的方式，它可以表示〜0，但不能。如果没有，那就是我称之为“深奥”的那些系统。技术上的错误是您想使用位运算符 ~ 而不是数字运算符。请参阅stackoverflow.com/questions/1967360/… 这是您通常想要表达的内容。所以代码在使用更正确的表达式时错误更少。是的，我经历过一次。不过那是很久以前的事了，上次被问到我已经无法从脑海中重现了。
@hakre，我已经撤消了编辑。这是关于硬科学，而不是语义。两者在技术上都是正确的。直到您命名一台机器，其中error_reporting(-1) 为您提供与error_reporting(~0) 不同的观察行为。

【解决方案4】：

在较新的 PHP 版本中，E_ALL 包含更多类别的错误。自 PHP 5.3 起，E_ALL 包含所有除了 E_STRICT。据称在 PHP 6 中它甚至会包含这些内容。这是一个很好的提示：最好是看到更多而不是更少的错误消息。

E_ALL 中包含的内容记录在在线手册的PHP predefined constants 页面中。

就个人而言，我认为使用 E_STRICT 并不重要。它当然不会伤害您，尤其是因为它可能会阻止您编写在 PHP 的未来版本中被破坏的可能性很小的脚本。另一方面，在某些情况下，严格的消息可能过于嘈杂，尤其是在您赶时间的情况下。建议你默认开启，烦了就关闭。

【讨论】：

E_STRICT 自 5.4 起包含在 E_ALL 中。

【解决方案5】：

根据您对此代码的长期支持计划，启用E_STRICT 进行调试可能有助于您的代码在遥远的将来继续工作，但对于日常使用来说可能有点过头了。关于E_STRICT，有两点需要牢记：

Per the manual，大多数 E_STRICT 错误是在编译时生成的，而不是运行时。如果您在代码中将错误级别提高到 E_ALL（而不是通过 php.ini），您可能永远不会看到 E_STRICT 错误。
E_STRICT 在 PHP 6 下包含在 E_ALL 中，但在 PHP 5 下不包含。如果您将服务器升级到 PHP6，并按照上面 #1 中所述配置 E_ALL，您将开始看到 E_STRICT 错误需要您进行任何其他更改。

【讨论】：

E_STRICT 自 5.4 起包含在 E_ALL 中。不是 PHP 6

【解决方案6】：

严格说来不是 error_reporting，我强烈建议使用任何自动显示解析错误和常见故障（例如，条件赋值）的 IDE。

Zend Studio for Eclipse 已默认启用此功能，自从我开始使用它以来，它一直在帮助我很多在错误发生之前发现错误。

例如，我在这段代码中缓存了$GLOBALS 变量中的一些数据，但我无意中写了$_GLOBALS。数据从来没有被缓存过，如果 Zend 没有告诉我：“嘿，这个 $_GLOBALS 东西只出现一次，那可能是一个错误”。

【讨论】：

【解决方案7】：

在 php.ini 中使用以下内容：

error_reporting = E_ALL | E_STRICT

您还应该安装Xdebug，它可以突出显示您在炫目的色彩方面的错误并打印有用的详细信息。

永远不要让代码中出现任何错误或通知，即使它是无害的。

【讨论】：

【解决方案8】：

您可以使用error_reporting = -1
它总是由所有位组成（即使它们不在 E_ALL 中）

【讨论】：