开发时推荐的 error_reporting() 设置是什么？ 那么 E_STRICT 呢？
通常，我使用 E_ALL 来查看 PHP 可能对我的代码说的任何内容，以尝试改进它。
我刚刚注意到一个错误常量 E_STRICT，但从未使用或听说过它，这是用于开发的良好设置吗？ 手册说：
运行时通知。 启用 PHP 建议对代码进行更改，这将确保代码的最佳互操作性和前向兼容性。
所以我想知道我是否使用了 E_ALL 的最佳 error_reporting 级别，或者与 E_STRICT 一起使用是最好的吗？ 或者还有其他我还没有学会的组合吗？
Typically I use E_ALL to see anything that PHP might say about my code to try and improve it.
I just noticed a error constant E_STRICT, but have never used or heard about it, is this a good setting to use for development? The manual says:
Run-time notices. Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.
So I'm wondering if I'm using the best error_reporting level with E_ALL or would that along with E_STRICT be the best? Or is there any other combination I've yet to learn?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
在 PHP 5 中，
E_STRICT涵盖的内容并没有被E_ALL涵盖，因此要获取最多的信息，需要将它们组合起来：在 PHP 5.4 中，
E_STRICT将包含在E_ALL中，因此您可以仅使用E_ALL。您还可以使用
它始终启用所有错误。 哪个在语义上更正确：
In PHP 5, the things covered by
E_STRICTare not covered byE_ALL, so to get the most information, you need to combine them:In PHP 5.4,
E_STRICTwill be included inE_ALL, so you can use justE_ALL.You can also use
which will always enable all errors. Which is more semantically correct as:
在 php.ini 中使用以下内容：
您还应该安装 Xdebug，它可以突出显示盲法中的错误色彩鲜艳并打印有用的详细信息。
永远不要让代码中出现任何错误或通知，即使它是无害的。
Use the following in php.ini:
Also you should install Xdebug, it can highlight your errors in blinding bright colors and print useful detailed information.
Never let any error or notice in your code, even if it's harmless.
我认为，在开发阶段将错误报告级别设置得越高越好。
在实时环境中，您希望稍微（但只是稍微）减少集合，但希望将它们记录在用户看不到的地方（我更喜欢
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 中得到修复......In my opinion, the higher you set the error reporting level in development phase, the better.
In a live environment, you want a slightly (but only slightly) reduced set, but you want them logged somewhere that they can't be seen by the user (I prefer
syslog).http://php.net/error_reporting
E_ALL | E_STRICTfor development with PHP before 5.2.0.5.2 introduces
E_RECOVERABLE_ERRORand 5.3 introducesE_DEPRECATEDandE_USER_DEPRECATED. You'll probably want to turn those on if you're running one of those versions.If you wanted to use magic numbers you could just set the
error_reportingvalue to some fairly high value of2^n-1- say,16777215, and that would really just turn on all the bits between1..n. But I don't think using magic numbers is a good idea...In my opinion, PHP has dropped the ball a bit by having
E_ALLnot really be all. But apparently it's going to be fixed in PHP 6...在较新的 PHP 版本中，E_ALL 包含更多类别的错误。 从 PHP 5.3 开始，E_ALL 包含除 E_STRICT 之外的所有内容。 据称在 PHP 6 中甚至会包含这一点。 这是一个很好的提示：看到更多的错误消息比看到更少的错误消息更好。
E_ALL 中包含的内容记录在 PHP 预定义常量 页面中在线手册。
就我个人而言，我认为使用 E_STRICT 并不重要。 它当然不会伤害您，特别是因为它可能会阻止您编写在未来版本的 PHP 中极有可能被破坏的脚本。 另一方面，在某些情况下，严格的消息可能会太吵闹，尤其是在您很赶时间的情况下。 我建议你默认打开它，当它变得烦人时将其关闭。
In newer PHP versions, E_ALL includes more classes of errors. Since PHP 5.3, E_ALL includes everything except E_STRICT. In PHP 6 it will alledgedly include even that. This is a good hint: it's better to see more error messages rather than less.
What's included in E_ALL is documented in the PHP predefined constants page in the online manual.
Personally, I think it doesn't matter all that much if you use E_STRICT. It certainly won't hurt you, especially since it may prevent you from writing scripts that have a small chance of getting broken in future versions of PHP. On the other hand, in some cases strict messages may be too noisy, perhaps especially if you're in a hurry. I suggest that you turn it on by default and turn it off when it gets annoying.
您可以使用
error_reporting = -1它始终包含所有位（即使它们不在 E_ALL 中）
You may use
error_reporting = -1It will always consist of all bits (even if they are not in E_ALL)
根据您对此代码的长期支持计划，启用
E_STRICT进行调试可能会帮助您的代码在遥远的将来继续工作，但对于日常使用来说可能有点过分了。 关于E_STRICT有两件重要的事情需要记住：E_STRICT错误是在编译时生成的，而不是运行时生成的。 如果您在代码中将错误级别提高到E_ALL（而不是通过 php.ini），您可能永远不会看到E_STRICT错误。E_STRICT包含在 PHP 6 下的E_ALL中，但不在 PHP 5 下。如果您将服务器升级到 PHP6，并且按照说明配置了E_ALL在上面的 #1 中，您将开始看到E_STRICT错误，而无需您进行任何其他更改。Depending on your long term support plans for this code, debugging with
E_STRICTenabled may help your code to continue working in the distant future, but it is probably overkill for day-to-day use. There are two important things aboutE_STRICTto keep in mind:E_STRICTerrors are generated at compile time, not runtime. If you are increasing the error level toE_ALLwithin your code (and not via php.ini), you may never seeE_STRICTerrors anyway.E_STRICTis contained withinE_ALLunder PHP 6, but not under PHP 5. If you upgrade your server to PHP6, and haveE_ALLconfigured as described in #1 above, you will begin to seeE_STRICTerrors without requiring any additional changes on your part.严格来说，不是 error_reporting，我强烈建议使用任何能够自动显示解析错误和常见故障（例如，条件赋值）的 IDE。
Zend Studio for Eclipse 默认启用此功能，自从我开始使用它以来，它在错误发生之前捕获错误方面对我帮助很大。
例如，我有一段代码，我在 $GLOBALS 变量中缓存一些数据，但我无意中写了
$_GLOBALS。 数据从未被缓存，而且我永远不知道 Zend 是否没有告诉我：“嘿，这个$_GLOBALS东西只出现一次，这可能是一个错误”。Not strictly speaking of error_reporting, I'd strongly suggest using any IDE that automatically shows parsing errors and common glitches (eg, assignment in condition).
Zend Studio for Eclipse has this feature enabled by default, and since I started using it, it has been helping me a lot at catching errors before they occur.
For example, I had this piece of code where I was caching some data in the
$GLOBALSvariable, but I inadvertently wrote$_GLOBALSinstead. The data never got cached up, and I'd never knew if Zend didn't tell me: "Hey, this$_GLOBALSthingy appears only once, that might be an error".ini_set("显示错误","2");
错误报告（E_ALL）；
ini_set("display_errors","2");
ERROR_REPORTING(E_ALL);