为什么在PHP中禁用E_WARNING被认为是不正确的做法？

Question

据我了解，至少对于PHP v7.3，这是Production系统的“最佳实践” 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);

这会在底层发出警告，从长远来看，这将对项目中的代码质量不利。到目前为止，很明显，忽略警告是一种不好的做法。

但是，让我们在混合中添加另一个因素。如果出现reported错误，通常会配置一个自定义PHP错误处理程序以停止执行。例如，Yii1 handleError函数终止应用程序。我想象许多PHP框架都采用相同的方法。实际上，这会引起一些混乱，因为php docs说：

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

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

在我当前的项目中，E_WARNING是在测试系统上报告的，但目前不在生产中，并且可能需要80个小时来修复所有警告，以便我们可以启用它并遵循最佳实践。我认为这值得付出努力，我将向团队提出建议，但我需要对项目有一些好处，否则我们的投资回报率将被认为过低。到目前为止，我只有2种好处：

长期来看，这对于代码质量最好。
如果发生警告，可能会导致安全中断。我可以想到的一个示例是，警告可能与无效的正则表达式有关（过去已知无效的正则表达式容易受到攻击）。有时在正则表达式中使用用户输入，这肯定会打开攻击向量。

您能想到其他原因吗？

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

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

Answer 1

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

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

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

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