at 符号用于隐藏错误消息。据我所知,绝对没有使用它的用例或借口。
- 您可以通过更改 php ini 设置来隐藏生产中的错误,同时仍将错误输出到日志文件
- @-sign 使其他程序员很难确定问题出在哪里
- 错误消息是您开发时的朋友。快速发现错误并修复它们
我的一个朋友刚刚花了几个小时试图找出为什么该软件可以在一个系统上运行而不能在另一个系统上运行。如果库开发人员不使用@-sign,这将花费大约 10 秒。
当我说@-sign 绝对没有价值时,我是否心胸狭窄,是否有有效案例?
at 符号用于隐藏错误消息。据我所知,绝对没有使用它的用例或借口。
我的一个朋友刚刚花了几个小时试图找出为什么该软件可以在一个系统上运行而不能在另一个系统上运行。如果库开发人员不使用@-sign,这将花费大约 10 秒。
当我说@-sign 绝对没有价值时,我是否心胸狭窄,是否有有效案例?
@ 符号有一些价值,但它通常是一种代码味道。
考虑以下情况:您正在开发一个需要与多个项目兼容的库,并且您不想全局更改错误处理程序。不幸的是,许多 PHP 函数(包括与套接字和流相关的函数)在失败时抛出 PHP 错误而不是异常。当且仅当手动检查错误并在发生异常时抛出异常时,“@”符号对于隐藏错误很有用。
它对文件系统操作也很有用。
主要是你是对的......这通常是可怕的做法(:
在极少数情况下,使用错误抑制确实有意义。
其中之一是原子文件系统操作。例如,而不是写作
if (file_exists($fileName)) {
unlink($fileName);
}
你只是做
@unlink($fileName);
这可以确保您的代码不受竞争条件的影响。
通常在PHP 为函数选择不合适的错误模型@
的情况下很有用。上述函数就是一个这样的例子。类似地,还有一些 PHP 会抛出错误的函数,即使它不应该抛出错误(而是使用返回值或可捕获的异常)。unlink
在大多数情况下,您确实不应该使用它。在某些情况下,它是有道理的:
unlink()
while (@ob_end_flush());
可能还有其他一些极端情况,但除此之外,你真的永远不应该抑制错误。
与所有可用的工具一样(无论是在编程中还是在编程之外),一切都有一个合法的用例。
对于错误抑制运算符,想到的第一个示例类似于
if (!@unlink($file)) {
// I am already handling the error. I don't care what caused it.
// Even NOT handling this case at all could be a legitimate reaction
// depending on circumstances.
}
我见过的最常见的地方是在使用 db 时抑制 mysql 错误。然后用户检查响应并打印适当的错误消息。
例子
<?php
$link = @mysql_connect('localhost', 'mysql_user', 'mysql_password');
if (!$link) {
die('Could not connect: ' . mysql_error());
}
echo 'Connected successfully';
mysql_close($link);
?>
我还看到它在使用 ftps 和 sftps 时使用。
但我同意你的观点,我发现它的用途有限。如果最终遇到需要在自己生成的代码中使用@-sign 的情况,我认为是时候重新考虑解决方案了。
DOMDocument
,无效的 HTML 会抛出警告,大多数情况下我们并不关心。Mail
,您会收到有关不应静态调用的函数的警告,这是因为Mail
支持 PHP 4。这些可以安全地忽略。unlink()
,您可以抑制错误以防止出现竞争条件。