为什么在 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 小时，以便我们启用它并遵循最佳实践。 我认为这是值得的，我会向团队提出建议，但我需要为项目带来一些好处，否则投资回报率会被认为太低。 到目前为止，我只有 2 个好处：

1. 从长远来看，这对代码质量是最好的。
2. 如果出现警告，不停止可能是一个安全问题。 我能想到的一个例子是警告可能与无效的正则表达式有关（过去已知无效的正则表达式容易受到攻击）。 有时在正则表达式中使用用户输入，这肯定会打开攻击向量。

你能想到其他原因吗？

---

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

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

Answer 1

您应该将所有警告视为错误。 基本上，警告是不会停止脚本执行的错误。 在这种情况下，它们可以被认为比错误更危险。 如果前面的操作失败，您通常不希望应用程序继续执行。 这对于编码错误的程序来说可能是灾难性的。

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

计划在未来的 PHP 版本中提高所有错误的严重性。 请参阅https://wiki.php.net/rfc/engine_warnings

如果您可以忽略所有警告并且您的代码仍然正确执行，则表明存在严重的代码异味。 应尽快记录并修复所有警告。 不应将它们视为潜在错误，而应将其视为现有错误。

Answer 2

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