Question

我的php脚本中有一个外部包含文件，该文件在浏览器中执行时会触发警告。因此，我在其前面加上了@字符，非常好，现在警告不再发生。我的问题是，如果现在在CLI上执行脚本，则不会抑制该警告。如何也抑制CLI警告？

这是一个运行PHP 7.3的新VPS。

@include_once('externalsourcefile.php');

结果是：

警告：““ continue”定向开关等效于“ break”。您是要使用“ continue 2”吗？”在第XX行（externalsourcefile.php）

更新：关键是包含文件是外部源，我无法对其进行编辑以自行解决警告。

Answer 1

@不会抑制由文件内部代码生成的警告，只会抑制由include_once引起的错误和警告。

因此，如果无法加载文件，则不会出现任何错误，但是文件可以正确加载。然后，显然在第2行，将生成警告并返回给您。

Answer 2

您必须参考https://www.php.net/manual/en/function.include-once.php#84108，它将使您了解include_once的工作方式。您必须尽快删除@，这是不良作法！

if(include_once('externalsourcefile.php') == false) {
} else {
}

Answer 3

@禁止显示该语句的警告，在您的情况下为实际的include_once，而不是其中出现的内容。

我将其用作答案，因为评论太长。说@应该从不使用是错误的。

使用它不加思索。

考虑以下简单代码在繁忙的多进程环境中运行：

clearstatcache(true, $pathname);
if(is_dir($pathname) && $dh=opendir($pathname)) {
   // readdir() loop here
}else{
   // error handling here
}

此代码具有比赛条件。对于我而言，无数次发生在is_dir()返回和opendir()调用之间的目录消失之后，在控制台上发出警告：

PHP Warning:  opendir(/the/path/in/use): failed to open dir: No such file or directory in /path/to/script.php on line 2

我问你如何在不禁用opendir()的警告的情况下解决这场比赛？

与在上面的opendir()调用之类的特定语句上进行全局禁用相比，恕我直言更糟糕。

Answer 4

如前所述，该错误不是由include_once语句本身引起的，而是由包含文件中运行的代码引起的（可以通过仔细阅读错误消息来确定该错误）。

无论如何，它应该工作。肯定还有其他事情发生。

我可以想到三种可能性：

VPS中的CLI解释器配置为使用不支持custom error handler的error suppression operator：

对于error_types指定的错误类型，将完全绕过标准PHP错误处理程序，除非回调函数返回FALSE。 error_reporting()设置将无效，并且无论如何都将调用您的错误处理程序-但是您仍然可以读取error_reporting的当前值并采取适当的措施。特别需要注意的是，如果导致错误的语句由@ error-control运算符添加，则该值为0。
解释器已配置为调试，并且Xdebug已使用xdebug.scream directive进行了设置：

如果此设置为1，则Xdebug将禁用@（关闭）运算符，以便不再隐藏通知，警告和错误。
浏览器解释器正在运行的PHP版本早于CLI版本。 "continue" targeting switch is equivalent to "break" warning是PHP / 7.3中的向后不兼容的更改。之前没有触发警告。

在任何一种情况下，正如已经指出的那样，该问题本身表明抑制错误可能导致难以诊断的错误。