通常，我使用E_ALL来查看PHP可能对我的代码说的话，以尝试和改进它。

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

Run-time notices. Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.

因此，我想知道我是将最佳的error_reporting级别用于E_ALL还是将其与最佳的E_STRICT一起使用？还是我还需要学习其他组合吗？

解决方案

回答

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

回答

我认为，在开发阶段将错误报告级别设置得越高，效果越好。

在实际环境中，我们需要一个略微(但仅略微)的精简集，但我们希望它们记录在用户无法看到的地方(我更喜欢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中修复...

回答

在PHP 5中，E_STRICT涵盖的内容未包含在E_ALL的涵盖范围内，因此，为了获得最多的信息，我们需要将它们结合起来：

error_reporting(E_ALL | E_STRICT);

在PHP 5.4中，E_STRICT将包含在E_ALL中，因此我们只能使用E_ALL。

我们也可以使用

error_reporting(-1);

这将始终启用所有错误。语义上更正确的是：

error_reporting(~0);

回答

在较新的PHP版本中，E_ALL包含更多类别的错误。从PHP 5.3开始，E_ALL包含除E_STRICT之外的所有内容。在PHP 6中，它甚至将包括在内。这是一个很好的提示：最好看到更多错误消息，而不是更少。

在线手册的PHP预定义常量页面中记录了E_ALL中包含的内容。

就个人而言，我认为如果我们使用E_STRICT并没有多大关系。它当然不会伤害我们，尤其是因为它可能会阻止我们编写在将来的PHP版本中可能被破坏的脚本。另一方面，在某些情况下，严格的消息可能过于嘈杂，尤其是在我们急于处理时。我建议我们默认将其打开，并在烦人时将其关闭。

回答

根据我们对该代码的长期支持计划，启用E_STRICT进行调试可能会帮助代码在遥远的将来继续工作，但对于日常使用而言可能会显得过头。要记住有关E_STRICT的两件重要事情：

• 根据手册，大多数E_STRICT错误是在编译时而不是运行时生成的。如果我们在代码中将错误级别提高到" E_ALL"(而不是通过php.ini)，无论如何我们可能永远都不会看到" E_STRICT"错误。
• " E_STRICT"包含在PHP 6中的" E_ALL"中，但不包含在PHP 5中。如果将服务器升级到PHP6，并按照上述＃1中的说明配置了" E_ALL"，我们将开始看到" E_STRICT"错误，而没有需要我们进行任何其他更改。

回答

不严格地说是error_reporting，我强烈建议使用任何会自动显示解析错误和常见故障(例如，条件分配)的IDE。

Zend Studio for Eclipse默认情况下启用了此功能，并且自从我开始使用它以来，它一直在帮助我在发现错误之前提供很多帮助。

例如，我有一段代码在$ GLOBALS变量中缓存一些数据，但是我无意中写了$ _GLOBALS。数据从未被缓存过，我也不知道Zend是否不会告诉我："嘿，这个$ _GLOBALS东西只会出现一次，这可能是一个错误"。

回答

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

error_reporting = E_ALL | E_STRICT

另外，我们还应该安装Xdebug，它可以使明亮的色彩突出显示错误并打印有用的详细信息。

即使代码无害，也切勿在代码中出现任何错误或者通知。