为什么在PHP中禁用E_WARNING被认为是不良实践？

Question

据我了解，至少在PHP v7.3中，这是“最佳实践”PHP error_reporting 值的适用于一个生产系统：

ini_set('error_reporting', E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED);

我注意到这个报告提到了 E_WARNING。

我对忽略警告的缺点很感兴趣，例如：

ini_set('error_reporting', E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED & ~E_WARNING);

这样会将警告信息掩盖，长远来看，这将对项目的代码质量产生不良影响。目前为止，忽略警告显然是一种不好的做法。

但是，让我们再加入另一个因素。通常配置自定义PHP错误处理程序以在引发报告的错误时停止应用程序是很常见的。例如，Yii1的handleError函数会终止应用程序。我想许多PHP框架采用了同样的方法。这实际上会造成一些混淆，因为php文档说：

E_WARNING 运行时警告（非致命错误）。脚本的执行不会停止。

但是（至少在Yii1中），如果E_WARNING包含在error_reporting值中，则脚本的执行将被终止（由于yii自定义错误处理程序）。

在我的当前项目中，在测试系统上报告了E_WARNING，但目前未在生产环境中报告，如果修复所有警告需要大约80个小时，以便我们可以启用它并遵循最佳实践。我认为这值得努力，并将向团队提议，但我需要提出一些有利于项目的好处，否则ROI将被认为太低。到目前为止，我只有两个好处：

1. 从长远来看，这将是代码质量最好的选择。
2. 如果警告发生而不终止可能会存在安全问题。我能想到的一个例子是，警告可能与无效的正则表达式有关（过去已知无效的正则表达式容易受到攻击）。有时用户输入也会用于正则表达式，这肯定会打开攻击通道。

你能想到其他原因吗？

总结一下我的问题（TL;DR）：

如果E_WARNING发生，不停止应用程序会有什么危险？

- Tom

---

说实话，我只读了TLDR。但你不应该压制警告，而应该处理它们。也就是说，你应该考虑到输入/数据出现问题，并采取相应的措施。抑制错误可能导致代码在没有适当数据的情况下运行，这可能会在管道的更深处引起问题。更多“防御性”的代码通常对最终用户更好（他们会收到关于自己做错了什么的消息），并且它确保只有适当的数据才能运行代码。 - Qirel

E_WARNING不会破坏应用程序的行为。因此，它只在开发环境中有用。没有人希望为最终用户显示未处理的警告消息。 - JessGabriel

Answer 1

你应该把所有警告都当作错误来处理。基本上，警告就是不会停止脚本执行的错误。在这种情况下，它们可能比错误更危险。如果前面的操作失败了，一般不希望应用程序继续执行。这对于编写糟糕的程序来说可能是灾难性的。

警告告诉您代码存在严重问题，而不是您的代码没有遵循最佳实践。

未来PHP版本计划增加所有错误的严重程度。请参见https://wiki.php.net/rfc/engine_warnings 如果你可以忽略所有警告并且你的代码仍然正确执行，那么这是一个严重的代码坏味道的迹象。所有警告都应该被记录并尽快修复。它们应该被视为现有的错误，而不是潜在的错误。

- Dharman

Answer 2

理想情况下，您的团队应该在软件进入生产（测试和 QA）之前解决所有警告的原因，毕竟隐藏的问题仍然是问题。这里有一个关于错误的不错的快速阅读here。

- Emerson