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

题

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

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

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

所以我想知道我是否使用了最好的 error_reporting 与 E_ALL 或者会连同 E_STRICT 做最好的？或者还有其他我还没有学会的组合吗？

解决方案

在 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.ini 中使用以下内容：

error_reporting = E_ALL | E_STRICT

你还应该安装调试工具, ，它可以突出显示您在令人眼花缭乱的明亮颜色中的错误并打印有用的详细信息。

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

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

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

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 版本中，E_ALL 包含更多类别的错误。从 PHP 5.3 开始，E_ALL 包含所有内容除了 E_STRICT。据称在 PHP 6 中甚至会包含这一点。这是一个很好的提示：看到更多的错误消息比看到更少的错误消息更好。

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

就我个人而言，我认为使用 E_STRICT 并不重要。它当然不会伤害您，特别是因为它可能会阻止您编写在未来版本的 PHP 中极有可能被破坏的脚本。另一方面，在某些情况下，严格的消息可能会太吵闹，尤其是在您很赶时间的情况下。我建议你默认打开它，当它变得烦人时将其关闭。

您可以使用 error_reporting = -1
它始终包含所有位（即使它们不在 E_ALL 中）

根据您对此代码的长期支持计划，使用 E_STRICT 启用可能有助于您的代码在遥远的将来继续工作，但对于日常使用来说可能有点过分了。有两件事很重要 E_STRICT 要牢记：

根据手册, ，最多 E_STRICT 错误是在编译时生成的，而不是运行时生成的。如果您将错误级别增加到 E_ALL 在您的代码中（而不是通过 php.ini），你可能永远不会看到 E_STRICT 无论如何都有错误。
E_STRICT 包含在 E_ALL 在 PHP 6 下，但不在 PHP 5 下。如果您将服务器升级到 PHP6，并且有 E_ALL 按照上面 #1 中的描述进行配置，您将开始看到 E_STRICT 错误，而不需要您进行任何额外的更改。

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

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

例如，我有这段代码，我在其中缓存一些数据 $GLOBALS 变量，但我无意中写了 $_GLOBALS 反而。数据从未被缓存，如果 Zend 没有告诉我，我永远不知道：“嘿，这个 $_GLOBALS thingy 只出现一次，这可能是一个错误”。

ini_set("显示错误","2");错误报告（E_ALL）；

许可以下： CC-BY-SA 和归因