为什么在 PHP 中禁用 E_WARNING 被认为是不好的做法？答案

【问题标题】：Why is disabling E_WARNING in PHP considered bad practice?为什么在 PHP 中禁用 E_WARNING 被认为是不好的做法？
【发布时间】：2019-11-29 12:29:51
【问题描述】：

据我了解，至少对于 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);

这会将警告隐藏在地毯下，从长远来看，这将不利于您项目中的代码质量。到目前为止，很明显忽略警告是一种不好的做法。

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

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

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

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

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

你还能想到其他原因吗？

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

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

【问题讨论】：

老实说，我刚刚阅读了 TLDR。但是你不应该压制警告，你应该处理它们。这意味着，您应该考虑输入/数据出现问题，并采取相应措施。抑制错误可能导致代码在没有适当数据的情况下运行，这可能会导致管道进一步出现问题。对于最终用户来说，更多“防御性”代码通常会更好（他们会收到有关他们做错了什么的消息），并且它可以确保代码仅使用适当的数据运行。
E_WARNING 不会破坏应用程序的行为。这就是为什么它只在开发环境中有用。没有人愿意为最终用户显示未处理的警告消息。

【解决方案1】：

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

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

计划在 PHP 的未来版本中增加所有错误的严重性。见https://wiki.php.net/rfc/engine_warnings

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

【讨论】：

【解决方案2】：

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

【讨论】：