代码之家  ›  专栏  ›  技术社区  ›  Tom

为什么在PHP中禁用E_警告被认为是不好的做法?

  •  1
  • Tom  · 技术社区  · 6 年前

    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);
    

    这会掩盖警告,从长远来看,这将对项目中的代码质量有害。到目前为止,忽视警告显然是一种不好的做法。

    报道 出现错误。例如,Yii1 handleError 函数终止应用程序。我想很多PHP框架都采用相同的方法。这实际上会引起一些混乱,因为 php docs 说:

    不停

    紧急警告 值(由于yii自定义错误处理程序)。

    紧急警告

    1. 从长远来看,这对代码质量是最好的。
    2. 如果出现警告,不停止可能是一个安全问题。我能想到的一个例子是,警告可能与无效的regexp有关(过去已知无效的regexp易受攻击)。有时,用户输入用于regexp,这无疑会打开攻击向量。


    总结我的问题(TL;DR) :

    如果出现以下情况,则不停止应用程序的危险是什么 发生?

    0 回复  |  直到 6 年前
        1
  •  2
  •   Dharman vijay    6 年前

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

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

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

    如果您可以忽略所有警告,并且代码仍然正确执行,那么这就是严重代码气味的迹象。应尽快记录并修复所有警告。它们不应被视为潜在的bug,而应被视为现有bug。

        2
  •  0
  •   Emerson    6 年前

    理想情况下,您的团队应该在您的软件投入生产(测试和QA)之前修复警告的所有原因,毕竟隐藏的问题仍然是一个问题。有一个关于错误的快速阅读 here .